1. 别急着装包先想清楚 conda 到底帮你管了什么先说个场景。前阵子公司来了个新同事工位刚配好电脑第一件事就是装 Python。他打开官网下载了 Python 3.12一路点下一步装完然后又去装 pandas、numpy、requests一通pip install下去世界安静了。第二天他跑一个深度学习项目需要 Python 3.8 的环境于是又装了 3.8结果打开命令行敲python发现版本还是 3.12而项目依赖的 TensorFlow 怎么装都报错。他问我为什么这么乱答案很简单——他身上缺一个叫 conda 的东西。不是非装不可但装了之后你会在各种 Python 项目之间切换得像喝水一样自然。conda 的核心价值不是“能安装软件包”而是“能把不同项目的依赖隔离成独立的小房间”每个房间有自己的 Python 版本、自己的库、自己的依赖树互不干扰。这才是它区别于 pip 的本质。如果你现在对 Python 的理解还停留在“装一个解释器然后 pip install 一切”那我建议你往下看。这篇文章我尽量不写成说明书式的干条条而是把我自己这几年在 conda 使用中踩过的坑、翻过车的操作、以及最后沉淀下来的习惯全部说出来。内容围绕的核心来自大家搜索最多的几个问题conda 怎么安装、conda 怎么创建虚拟环境、conda 和 pip 到底啥区别、conda 换源用什么源、conda 一直卡在 solving environment 怎么办、conda init 之后为什么提示 no change、conda 删环境怎么删干净。先直接说结论conda 不是一个简单的包管理器它是一个“环境 包”双重管理器。pip 只解决“装什么版本的库”conda 同时还解决“在哪个 Python 版本、哪个依赖集里装”。这也是为什么很多老手会让新手第一步就学 conda而不是直接裸装 Python。2. 安装、初始化与 PATH那一声声 not recognized 是怎么来的2.1 Windows 上最典型的安装翻车现场Windows 用户几乎十个里有七个会在配置 conda 时遇到过那句中文报错conda 不是内部或外部命令也不是可运行的程序或批处理文件。这句话看着吓人其实就两层意思第一conda 确实装了但没进系统 PATH第二你装的可能是 Anaconda但你打开的是普通的 CMD 或 PowerShell而 conda 默认要依赖 Anaconda Prompt 或者先跑conda init才能把环境变量注入到当前 shell。先说最简单的解决路径如果你装的是 Anaconda直接去开始菜单搜索 Anaconda Prompt 打开那里面 conda 是活的。如果你非要让普通 CMD 也能用 conda安装时勾选 Add Anaconda3 to my PATH environment variable——不过这里我要插一句官方乃至社区多数老手都不建议这么干。为什么因为 Anaconda 自带的 Python 会和系统里其他 Python 产生 PATH 抢占后面你可能出现一种诡异情况在 CMD 里敲python进的是 Anaconda但pip --version却指向另一个路径。与其让所有 shell 都认识 conda不如只在需要时激活。更推荐的做法是装 Miniconda后面会细讲它和 Anaconda 的区别装的时候同样不勾 PATH安装完打开 Anaconda Prompt 或者任意终端手动执行conda init它会帮你把 conda 的初始化脚本写进当前 shell 的配置文件比如 PowerShell 会改profile.ps1CMD 会改注册表里的 auto-runbash 会改.bashrc。重开一个终端再敲conda --version基本就活了。2.2 运行conda init之后显示 no change 是怎么回事这个坑我这几年见过不少次而且完美命中热搜词里的这条运行conda init 之后显示conda init no change c:\software_install\anaconda\scr我第一次遇到也愣了一下以为没生效。其实 no change 不是报错它的意思是conda 检查你当前 shell 的配置文件发现相关的初始化代码已经写过了不需要再做任何修改。那问题来了既然 no change为什么我在终端里敲conda还是无效原因通常分几种你改完配置后没有重开终端窗口。conda init是修改配置文件的而终端在启动时只读取一次配置你得完全关掉重开或者重新加载配置PowerShell 里执行. $PROFILEbash 里执行source ~/.bashrc。你conda init的对象和你实际使用的 shell 不是同一个。比如你在 Anaconda Prompt 里执行了 init但平时用的是 VS Code 自带的终端或者 Windows Terminal 默认的 PowerShell这些终端启动时可能加载的是另一套配置。路径异常。像你这条信息里显示c:\software_install\anaconda\scr注意scr这个路径看起来像Scripts的截断说明 conda 内部拼接路径出了问题多半是因为安装路径包含空格或不规范字符导致初始化脚本没写对位置。解决办法不复杂先确认你的 conda 安装在哪个绝对路径再在终端手动执行一次conda init powershell如果你用的是 Windows Terminal PowerShell 组合init 完再关掉所有终端窗口重新开一个。还不行就直接把C:\software_install\anaconda\Scripts\conda.exe这个路径手动加进系统 PATH回头再慢慢排查路径问题。2.3 Ubuntu 下安装 conda 的稳妥步骤Linux 用户搜索“ubuntu 安装 conda”和“ubuntu 26安装conda”这类关键词的太多了。Ubuntu 下装 Miniconda 比 Windows 省心不少因为你要面对的不是 PATH 问题而是官方源下载速度极慢、以及后续 shell 配置激活的问题。我这里给一套我自己在 Ubuntu 20.04 / 22.04 上反复用过的流程# 1. 下载 Miniconda 安装脚本建议先到官网确认最新版本号 wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh # 2. 运行安装脚本 bash Miniconda3-latest-Linux-x86_64.sh # 3. 一路回车 yes安装在默认路径 ~/miniconda3 # 最后一步会问是否执行 conda init选 yes # 4. 重新加载配置文件 source ~/.bashrc # 5. 验证 conda --version这里有一个重要细节安装脚本最后问 Do you wish the installer to initialize Miniconda3 by running conda init? 时默认是 no。如果你手快按了回车没看到安装完会发现 conda 命令不存在。这时候不用重装手动执行一次~/miniconda3/bin/conda init bash source ~/.bashrc如果你用的是 zsh就把bash换成zsh。这条经验是我在给别人远程调试环境时被问过最多的问题之一其实 install 完先跑 conda init 是最顺的路径。至于“conda init 之后显示 no change”在 Linux 上也常见原因和 Windows 上一样——配置已经写过一次了但你是在没重开终端的情况下敲的 conda所以仍然无效。记住改完 shell 配置之后重开终端永远是最保险的第一步。3. 虚拟环境的生命周期创建、激活、删除与迁移3.1 为什么非要建虚拟环境我一上来就把所有包装在 base 里不行吗可以但你会后悔。base 环境是 conda 的根环境装完 Miniconda 或 Anaconda 之后base 里默认带了一整套 Python 和基础包Anaconda 带的尤其多。很多人图省事conda install xxx不带-n参数全装进 base。短时间看着没问题时间一长你会发现项目 A 要 pandas 1.5项目 B 要 pandas 2.0全装 base 里必然冲突conda 为了解析依赖会陷入永无止境的 solving environment。你想升级某个包但它是另一个项目的运行前提一升级那个项目就崩。哪天你删 base 或者重置 base所有环境一朝清零。所以正确的习惯是每个项目建一个独立环境环境之间物理隔离。我在本地机器上的习惯是base 永远保持干净只装 conda 和极少数的管理工具比如 mamba所有的项目依赖都放进独立环境里。3.2 最基本的增删改查命令一次说清# 创建新环境指定 Python 版本 conda create -n myproject python3.10 # 创建环境的同时安装一批包 conda create -n myproject python3.10 numpy pandas requests # 激活环境 conda activate myproject # 退出当前环境回到 base conda deactivate # 列出所有环境 conda env list # 删除环境加 -y 跳过确认 conda remove -n myproject --all -y # 从 environment.yml 创建环境团队协作最常用 conda env create -f environment.yml # 导出当前环境到文件 conda env export environment.yml这里提一个值得反复强调的细节conda create -n的时候可以不加 Python 版本conda 会默认用一个当前可用的版本。但建议你每次都显式指定版本比如python3.10。原因很简单很多包的兼容性跟 Python 版本强相关你不指定哪天不同项目创建的环境 Python 版本不一致依赖解析的结果也会不同容易埋坑。而且显式指定版本后conda 的 solver 会更快因为候选范围缩小了。3.3 删除环境之后残留文件怎么办热搜词里有“conda删除虚拟环境”。大部分人执行完conda remove -n xxx --all就以为万事大吉其实环境目录通常残留在~/miniconda3/envs/xxxWindows 上是C:\Users\你的用户名\miniconda3\envs\xxx。conda remove --all正常情况下会把这个目录删掉但偶尔由于文件占用比如某个 Python 进程还开着或权限问题会删不干净。遇到这种情况先确认没有进程在使用该环境的 Python然后手动删除目录。普通人不会经常遇到这种问题但一旦遇到别慌这是正常的。还有一个小细节删除环境前如果这个环境被 Jupyter kernel 注册过删完环境后jupyter kernelspec list里可能还会显示残留内核需要手动删jupyter kernelspec remove xxx这个坑我是真实踩过的做完环境清理后临时 kernels 还在导致别人连过来时一脸懵。3.4 环境迁移Linux 上装好的东西怎么挪到 Windows热搜词里有一条特别有意思“conda linux离线迁移到windows”。说实话跨平台的 conda 环境迁移我一直不建议用 environment.yml 去硬导因为不同平台默认源不同包版本解析结果也不同很多包在 Linux 上能装在 Windows 上根本不存在比如某些源码包依赖编译工具链。如果你真的要在离线状态下把 Linux 环境搬到 Windows我给两种思路第一种如果你只是要“相同的包版本”用conda env export --from-history导出这个命令只导出你显式安装的包和版本不带依赖树的哈希到 Windows 上重新建环境、装包最终版本大概率不一致但主要依赖可控。第二种如果是严格的“二进制一致”真正的做法不是 conda 去迁移而是用 Docker 把你的 Linux 环境打包成镜像在 Windows 上用 WSL2 跑 Docker。这属于曲线救国实际工作中比较常见。另外还有个工具叫 conda-pack它能把环境打包成一个 tar.gz解压即用适合同平台之间离线分发的场景。但请注意conda-pack 打包的环境在解压机器上不一定能直接用因为环境里的 prefix 路径是写死的你需要在目标机器上重新设置CONDA_PREFIX或者其他变量。说实话它更适合运维侧的离线部署不适合开发者的日常环境复制。4. 安装包老卡住solving environment、MemoryError 和换源全解析4.1 为什么一执行conda install就长时间卡在 solving environment这个可能是我见过最多人提问的场景之一。完美的热搜词命中conda中安装库一直卡在solving environment。什么是 solver简单讲conda 在装任何包之前会先读取你当前环境里所有已安装包的元数据然后和你要安装的新包联合起来寻找一组满足所有依赖约束的版本组合。默认的 solver 是经典求解器classic solver它是通过 SAT 求解器来枚举所有可能组合的当环境里包很多的时候组合爆炸求解时间从几十秒到几十分钟都有可能。我自己的体验是当你 base 环境里塞了 100 多个包再执行conda install一条新包求解过程出现 10 分钟以上的等待是很正常的。这时你以为是卡死其实它是在暴力求解。解决思路有三个层次。第一层增加超时时间或者耐心等待。但这个体验太差不推荐。第二层换用更快的求解器。conda 从 23.10 版本开始把 libmamba 作为默认 solver 的实验性支持你可以在你的 conda 配置里开启conda config --set solver libmambalibmamba 是 C 实现的求解器求解速度比经典 solver 快一个数量级以上。我实际感受是之前经典 solver 要 3 分钟的环境libmamba 基本 5 秒内出结果。强烈建议所有还剩经典 solver 的人切过去。第三层也是最重要的治本减少环境的体量。一个环境里装 200 个包conda 的 solver 永远快不了。合理做法是环境里只放那个项目真正需要的包能用 pip 装的纯 Python 包就尽量用 pip 装后面我会讲 conda 和 pip 的边界别让 conda 去解析那些纯 Python 的依赖树。4.2 MemoryError: The conda process ran out of memory 怎么破热搜词里有这么一条“conda memoryerror: the conda process ran out of memory. increase system memor”。这在 Windows 上出现的概率远高于 Linux。原因是 conda 的 solver 在处理大依赖树时需要大量内存默认的最大内存上限可能不够或者系统内存本身紧张。最简单的调整方式是在环境变量里设置# Windows 设置 conda 最大内存 set CONDA_MEMORY_LIMIT8GB这是 conda 从 23.x 版本开始支持的配置项。如果设完还是报 MemoryError优先考虑两条路一是换 libmamba solver上面写过二是把你这个环境里不需要的包清理掉再装新的。还有个小技巧如果你只是要临时装一个不重要的包并且不太在意版本精细度可以尝试conda install --freeze-installed这个参数会让 conda 不更新环境中已有的包只求解新增包依赖树范围小很多内存和耗时都能降下来。4.3 conda 换源选哪个源怎么换为什么换了还慢“conda换源”、“conda最新镜像源”、“conda国内镜像源”这几个热搜词背后其实是同一个痛点官方源在国外下载速度太慢。国内常见的镜像源有清华 TUNA、阿里云、中科大等。这里我不点名说哪个“最新”因为镜像地址更新很频繁我更建议你掌握换源的原理这样以后不管网址怎么变都能自己搞定。conda 的源配置写在.condarc文件里。Windows 用户路径通常是C:\Users\你的用户名\.condarcLinux 用户是~/.condarc如果文件不存在就新建一个。最简配置格式是channels: - defaults show_channel_urls: true想换成清华源你在终端里直接运行conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ conda config --set show_channel_urls yes国内镜像源曾经出过一个坑老版本镜像地址很多已经失效或迁移网上搜索到的一堆教程里写的链接根本打不开。所以我的建议是不要刷教程去镜像站的官网页面看当前最新地址然后手动写进.condarc。关于“conda 最新镜像源”这个话题我想多啰嗦一句很多人换完源之后发现下载速度依然很慢原因是 conda 安装包时还会访问repodata.json如果你的.condarc里写了多个 channel而且其中一个不稳定conda 会等它超时后再去下一个 channel这个等待过程非常折磨人。解决办法是尽量只留一个 channel 为默认别叠一堆源。另外有一种更优的思路如果你所在环境访问国外网络本身不慢那其实根本不需要国内镜像源。大家的痛点主要在于大体积的 conda 包比如科学计算库动辄 100MB如果网络条件允许开着系统代理直连 defaults 反而不容易遇到源同步延迟导致的“找不到包”。我自己在有两台机器一台走清华源一台走 defaults日常体验其实差别不大。这个就看个人网络环境了。4.4 实在不想用镜像源有什么硬核方案热搜词还有一条“conda 不用镜像源”挺有意思。说实话如果你因为版权、安全或者网络原因完全不想用任何第三方镜像又嫌官方源慢我提供几个方案下载.tar.bz2或.conda包本地安装conda install /path/to/package.conda这种离线包可以在官方网站下载然后用 conda 从本地文件安装不经过任何通道。适合网络极差或内网部署场景。使用 Miniforge 直接换到 conda-forge 通道。Miniforge 默认就走 conda-forge特别适合需要大量开源包、又不希望版权上有任何纠结的场景。关于 Miniforge 和版权问题的细节我放在后面章节专门展开。用 mamba 或 micromamba 代替 conda 来加快下载和求解。mamba 在解决依赖时用的库不同速度会快不少。这些方案各有各的适用场景不是每条路都适合所有人但至少可以让你在“不用镜像源”的前提下把 conda 用得舒服。5. conda install 与 pip install边界、混用与避坑5.1 它们到底哪里不同这是热搜词里被问爆了的一个问题。我直接从三个层面拆开讲。第一包来源。conda 安装的包来自 conda channel比如 defaults、conda-forge这些通道里的包很多是经过 conda 团队或社区重新编译打包的自带非 Python 依赖比如 C 库、二进制动态库。而 pip 安装的是 PyPI 上的 wheel 包或源码包更纯粹地只面向 Python系统级的依赖库里很多不打包需要靠你的系统自己装。第二依赖解析。conda 会检查一个包背后的完整依赖树包括非 Python 的二进制库所以它很慢但更完整。pip 默认只解析 Python 包依赖不会管你系统里有没有那个动态库因此在某些科学计算场景会装完直接 import 报错。第三环境管理。conda 自己管理环境可以指定 Python 版本。pip 只是“往当前解释器里装包”它本身没有任何环境隔离概念。所以“conda 和 pip”不是二选一而是互补关系用 conda 管好 Python 版本和环境用 pip 补装 conda 通道里没有的包。最直观的例子是你在 conda 环境里装 PyTorch官方写的是pip install torch torchvision torchaudio但你在 conda 里执行这种命令前真的建议先 conda 装好 CUDA 相关的依赖再用 pip 装 torch后者的依赖解析才能找到系统库。5.2 混用时的秩序问题很多人问既然两个都能装包那我到底用哪个装答案不是唯一的但我给一个自己一直遵守的铁律创造环境永远用 conda因为要管理 Python 版本。环境内基础库优先用 conda 装尤其那些有二进制后端的库比如 numpy、scipy、pandasconda 安装的版本与系统的兼容性更好。其他纯 Python 包或者 conda 通道没有的用 pip 装。这里有个大坑千万不要在同一个环境里交叉反复地 pip install 和 conda install。因为两者生成的依赖元数据各自维护conda 并不知道你 pip 装了哪些包pip 也不知道 conda 的依赖约束。交叉安装的次数多了环境的一致性就没法保证最终可能看起来一切都正常某天你conda install一个新包时conda 求解器检测到和 pip 已装包冲突直接给你报错甚至回滚掉你 pip 装的东西。如果实在避免不了混用有一个常规操作可以缓解先 pip install 的包尽量少而精装完立刻conda env export保存现场一旦出问题可以快速重建。另外pip 装包时记得用python -m pip而不是裸pip这样能保证 pip 确实是当前环境对应解释器的 pip避免装到 base 环境去。6. conda 在真实场景里的整合玩法VSCode、JupyterLab、GPU 与进阶工具6.1 VSCode 怎么识别 conda 环境搜索“vscode使用conda环境”、“vscode中链接conda终端”、“vscode配置conda”这类关键词的人基本都是想用 IDE 写代码结果发现解释器选不对。VSCode 用 conda 环境分两步先选解释器CtrlShiftP输入 Python: Select InterpreterVSCode 会列出它扫描到的所有 Python。由于 conda 环境的 Python 都在~/miniconda3/envs/xxx/bin/python.exeWindows或~/miniconda3/envs/xxx/bin/pythonLinux只要你安装了 Python 插件它一般能自动识别。识别不到的点“Enter interpreter path”手动填路径。再让终端进入该环境VSCode 终端默认走系统的 shell而不是 conda 环境。你想打开终端就自动 activate 某个环境可以在.vscode/settings.json里配置{ terminal.integrated.profiles.windows: { PowerShell: { source: PowerShell, args: [-NoExit, -Command, conda activate myproject] } } }不过说实话我更推荐的做法是不配这个——终端里手动敲conda activate myproject就完了简单直接。重点是要让 VSCode 的解释器选中这个环境终端进去后也确认下python --version和which python是否指向那个环境的路径。6.2 JupyterLab 打开的常见问题SSL、内核与网页版热搜词里有两条特别具体“conda怎么打开网页版jupyter”、“win11 conda 配置jupyterlab 提示ssl.sslerror {asn1: not_engou} not engou”这条被输入截断了一半但能看出是 SSL 相关 ASN1 错误。先回答最简单的在激活某个环境后执行jupyter lab终端会打印一串 URL其中包含一个带 token 的本地地址用浏览器打开即可。如果你希望 Jupyter 能识别不同的 conda 环境内核需要安装ipykernel然后在对应环境里执行conda install ipykernel python -m ipykernel install --user --name myproject --display-name Python (myproject)这样每次打开 Jupyter新建 Notebook 的时候就能在 Kernel 菜单里看到你的环境。关于 Windows 11 上配置 JupyterLab 遇到 SSL 报错这种问题本质上是 OpenSSL 版本或证书链的问题不是 conda 本身的问题。但有一个经典原因conda 环境里的 OpenSSL 版本过高或过低和 Jupyter 的 websocket 加密连接不兼容。我的排查思路是分三步走先看报错是发生在浏览器访问时还是 Jupyter 启动时如果是启动阶段在 Python 里检查环境和版本可以用conda list openssl看 openssl 版本升级或降级后再试如果升级 openssl 没用就查看是否系统代理干扰了本机回环请求。还有一个更省事的方案直接用 VSCode 写 Jupyter Notebook把 Jupyter 服务器拉到 VSCode 里面跑少一层浏览器的 SSL 日志干扰问题往往就不见了。6.3 手把手搞定 TensorFlow-GPU 环境的版本匹配关于“手把手教你用conda搞定tensorflow-gpu环境(附版本对照表)”这个主题我太熟悉了。很多人在这一步翻车基本都是因为版本对应关系混乱TensorFlow 版本、Python 版本、CUDA 版本、cuDNN 版本四个维度只要有一个不匹配import tensorflow 就会报错。这里我给一个我在本地机器上实测过很多次的稳定组合参考组件推荐版本截止 2024 年初一个稳定的组合Python3.10TensorFlow2.12 或 2.13CUDA11.8cuDNN8.6创建命令如下conda create -n tf_gpu python3.10 -y conda activate tf_gpu conda install cudatoolkit11.8 cudnn8.6 -y pip install tensorflow2.12注意这个组合不是“唯一正确”的答案。因为 NVIDIA 驱动、系统 CUDA 驱动、conda 包通道的变化版本映射关系会变。最稳妥的办法是去 TensorFlow 官网查看当前官方测试过的版本对应表然后利用nvidia-smi查看自己的显卡驱动支持的最高 CUDA 版本再决定选择哪个 CUDA 版本。不要把驱动版本、conda 包里的 cudatoolkit 版本和系统级 CUDA 混为一谈——你 conda 里装的 cudatoolkit 只是运行时库它不需要与系统 CUDA 驱动完全一致但系统驱动必须满足最低版本要求。另外在某些 Windows 环境里TensorFlow 从 2.11 开始不再支持原生 Windows GPU。是的Windows 用户没法只用 pip 装 tf 2.11 来直接用 GPU。很多老帖子上装的是 2.10这是 Windows 原生 GPU 支持的最后一块拼图。后来也有人通过 WSL2 跑 Linux 版的 TensorFlow这也是一条路径但不在本文展开。6.4 用 conda 装 Xinference 等大模型推理框架的注意事项热搜词里“conda安装xinference”出现了多次。Xinference 是一个大语言模型推理框架它依赖非常重尤其是不同模型需要不同的推理后端pip 装体积很大。我的建议是专门为它建一个独立环境原因很简单Xinference 的依赖树里有很多库会和你的日常数据处理库冲突直接装进你平时用的数据分析环境几乎必然破坏现有依赖。做法如下conda create -n xinference python3.10 -y conda activate xinference pip install xinference[all]注意Xinference 官方推荐用 pip 安装conda 通道里没有正式的包。用 conda 只负责建环境、配 Python 版本实际依赖还是 pip 管。这就是我上面说的互补关系的最典型案例。6.5 Miniforge、conda-forge 与版权问题这是个很容易被人忽略但实际很重要的点。Anaconda 商业版在 2020 年开始调整了 ToS公司员工数量超过一定规模并且不是非营利组织或学校的情况下使用 Anaconda 的默认源defaults需要购买商业授权。个人开发者无所谓但如果你在公司环境里大规模使用 Anaconda你的法务部门可能会找上你。解决思路就是热搜词里提到的使用 conda-forge 或 Miniforge。Miniforge 是一个社区维护的、基于 conda 的最小化发行版它默认配置的 channel 是 conda-forge这是一个由社区驱动、相对宽松的频道没有 Anaconda 商业授权的限制问题。安装方式基本和 Miniconda 一样只是下载地址不同。我自己有两台开发机一台装了 Miniconda 用 defaults个人项目一台装了 Miniforge 走 conda-forge公司项目。切换后的最大感受是conda-forge 上有非常多 defaults 里没有的包有些包甚至更新时间比 defaults 还快比如一些科研向的冷门库。缺点则是 conda-forge 的包一致性维护非常严格某些包求解时间反而长一些不过 libmamba solver 把这个体验拉回来了。6.6 conda 和 uv新工具来了旧工具还有没有必要学这个热搜词条直指一个新趋势uv一个用 Rust 写的极快的 Python 包管理工具。它在 PyPI 生态里异常火爆主打“快到你怀疑人生”。很多人开始纠结既然 uv 这么香那我还有必要学 conda 吗我的观察是it depends。uv 主要解决的是 pip 层面的效率问题它也能做虚拟环境管理但它不解决系统级依赖CUDA、MKL的安装问题和 pip 一样它只关心 Python 包不关心你系统里的动态库。而你用 conda 的很大一个理由恰恰是 conda 能同时装好二进制依赖并保证环境内的一致性。你完全可以组合使用conda 维护 Python 版本和系统级库cudatoolkit、mkl、ffmpeg 这类uv 负责 Python 包的超快速解析和安装。我个人的真实习惯已经演变成conda 建环境uv pip install 装包。这样做的好处是conda 帮你锁住系统级依赖uv 帮你加速 Python 包的安装两边各管各的彼此不冲突。但请注意我把 uv 当作 pip 的替代品而不是混着用——如果你两个都在环境里装包同样会有元数据不一致的问题。6.7 环境列表用命令行怎么查Linux 系统下用 conda 命令查虚拟环境列表最简单的方式conda env list或者conda info --envs这两个命令等价。如果要看某个环境里具体装了哪些包conda list -n myproject如果想看当前激活环境的包列表直接conda list。这条热搜词虽然简单但被搜索的次数非常多我猜可能是因为很多人刚接触 conda 时看教程说“执行 conda env list 查看环境”结果把env和list的关系搞混敲成conda list env。这里注意了conda list的命令参数是包相关的语义跟环境列表没有直接关系别拼错了。7. 我的 conda 使用习惯几条不谈技术细节但很救命的心得最后不做什么总结了就聊几条我这几年养成的习惯希望能帮你少走点弯路。第一条新电脑装 Python 环境我永远先装 Miniconda而不是 Anaconda。Anaconda 自带几百个包听着方便其实大部分你根本用不到还会拖慢 conda 的 solver 速度让每次 install 都变慢。Miniconda 只有 conda、Python 和极少的系统依赖从零开始装项目需要的包环境清爽排查问题也容易。等到你真的发现自己需要 Anaconda 那几十个默认包时多半已经知道自己在干什么了不需要靠 Anaconda 的那套全家桶去兜底。第二条环境命名要带项目语义不要用 python3、test123 这种容易混淆的名字。我的一般规则是数据分析就用>conda env export environment.yml不过要注意conda env export默认会导出大量精确到哈希的依赖恢复时不一定能在其他平台复现。如果你只是给其他开发者提供一个能用的还原入口我更推荐conda env export --from-history这个命令只导出你显式指定过的包没了依赖树的深层哈希在其他机器上重建环境时conda 会重新解析依赖兼容性更好。说实话这个技巧网上很少有人提但它对我实际帮同事恢复环境时帮了大忙。第四条遇到 conda 的诡异问题先做两个检查——看 conda 版本再看 solver 类型。很多问题在升级 conda 到最新版、切到 libmamba solver 之后自动消失了。如果你还卡在很老的 conda 版本上别急着去搜具体的报错信息先把 conda 本体升上去conda update conda -n base然后再试大概率很多玄学问题都没了。第五条也是最后一条不要怕 conda 慢就弃用要学会“换工具”而不是“硬等”。当你直觉觉得某个环境装东西越装越慢、越装越乱最省心的操作是直接删掉这个环境重开一个干净的用--from-history导出的清单重新装一遍。一个从零开始的环境往往比一个修修补补的环境稳定得多这跟你重装系统一个道理。我在过去几个月里已经不止一次靠“删掉重来”解决了连官方 issue 都说不清的环境病。conda 这东西本质上就是一个帮你管理“混乱”的工具。用得好它让混乱保持在可控范围用得不好它自己也能变成另一个混乱源头。希望这篇偏实战经验的分享能给你一些参考。如果你也有什么 conda 相关的翻车现场欢迎在评论区分享出来说不定下一个被大家高频搜索的疑难杂症就是从你这条评论里面抽出的关键词。
conda 实战指南：环境隔离、换源加速与疑难排查
1. 别急着装包先想清楚 conda 到底帮你管了什么先说个场景。前阵子公司来了个新同事工位刚配好电脑第一件事就是装 Python。他打开官网下载了 Python 3.12一路点下一步装完然后又去装 pandas、numpy、requests一通pip install下去世界安静了。第二天他跑一个深度学习项目需要 Python 3.8 的环境于是又装了 3.8结果打开命令行敲python发现版本还是 3.12而项目依赖的 TensorFlow 怎么装都报错。他问我为什么这么乱答案很简单——他身上缺一个叫 conda 的东西。不是非装不可但装了之后你会在各种 Python 项目之间切换得像喝水一样自然。conda 的核心价值不是“能安装软件包”而是“能把不同项目的依赖隔离成独立的小房间”每个房间有自己的 Python 版本、自己的库、自己的依赖树互不干扰。这才是它区别于 pip 的本质。如果你现在对 Python 的理解还停留在“装一个解释器然后 pip install 一切”那我建议你往下看。这篇文章我尽量不写成说明书式的干条条而是把我自己这几年在 conda 使用中踩过的坑、翻过车的操作、以及最后沉淀下来的习惯全部说出来。内容围绕的核心来自大家搜索最多的几个问题conda 怎么安装、conda 怎么创建虚拟环境、conda 和 pip 到底啥区别、conda 换源用什么源、conda 一直卡在 solving environment 怎么办、conda init 之后为什么提示 no change、conda 删环境怎么删干净。先直接说结论conda 不是一个简单的包管理器它是一个“环境 包”双重管理器。pip 只解决“装什么版本的库”conda 同时还解决“在哪个 Python 版本、哪个依赖集里装”。这也是为什么很多老手会让新手第一步就学 conda而不是直接裸装 Python。2. 安装、初始化与 PATH那一声声 not recognized 是怎么来的2.1 Windows 上最典型的安装翻车现场Windows 用户几乎十个里有七个会在配置 conda 时遇到过那句中文报错conda 不是内部或外部命令也不是可运行的程序或批处理文件。这句话看着吓人其实就两层意思第一conda 确实装了但没进系统 PATH第二你装的可能是 Anaconda但你打开的是普通的 CMD 或 PowerShell而 conda 默认要依赖 Anaconda Prompt 或者先跑conda init才能把环境变量注入到当前 shell。先说最简单的解决路径如果你装的是 Anaconda直接去开始菜单搜索 Anaconda Prompt 打开那里面 conda 是活的。如果你非要让普通 CMD 也能用 conda安装时勾选 Add Anaconda3 to my PATH environment variable——不过这里我要插一句官方乃至社区多数老手都不建议这么干。为什么因为 Anaconda 自带的 Python 会和系统里其他 Python 产生 PATH 抢占后面你可能出现一种诡异情况在 CMD 里敲python进的是 Anaconda但pip --version却指向另一个路径。与其让所有 shell 都认识 conda不如只在需要时激活。更推荐的做法是装 Miniconda后面会细讲它和 Anaconda 的区别装的时候同样不勾 PATH安装完打开 Anaconda Prompt 或者任意终端手动执行conda init它会帮你把 conda 的初始化脚本写进当前 shell 的配置文件比如 PowerShell 会改profile.ps1CMD 会改注册表里的 auto-runbash 会改.bashrc。重开一个终端再敲conda --version基本就活了。2.2 运行conda init之后显示 no change 是怎么回事这个坑我这几年见过不少次而且完美命中热搜词里的这条运行conda init 之后显示conda init no change c:\software_install\anaconda\scr我第一次遇到也愣了一下以为没生效。其实 no change 不是报错它的意思是conda 检查你当前 shell 的配置文件发现相关的初始化代码已经写过了不需要再做任何修改。那问题来了既然 no change为什么我在终端里敲conda还是无效原因通常分几种你改完配置后没有重开终端窗口。conda init是修改配置文件的而终端在启动时只读取一次配置你得完全关掉重开或者重新加载配置PowerShell 里执行. $PROFILEbash 里执行source ~/.bashrc。你conda init的对象和你实际使用的 shell 不是同一个。比如你在 Anaconda Prompt 里执行了 init但平时用的是 VS Code 自带的终端或者 Windows Terminal 默认的 PowerShell这些终端启动时可能加载的是另一套配置。路径异常。像你这条信息里显示c:\software_install\anaconda\scr注意scr这个路径看起来像Scripts的截断说明 conda 内部拼接路径出了问题多半是因为安装路径包含空格或不规范字符导致初始化脚本没写对位置。解决办法不复杂先确认你的 conda 安装在哪个绝对路径再在终端手动执行一次conda init powershell如果你用的是 Windows Terminal PowerShell 组合init 完再关掉所有终端窗口重新开一个。还不行就直接把C:\software_install\anaconda\Scripts\conda.exe这个路径手动加进系统 PATH回头再慢慢排查路径问题。2.3 Ubuntu 下安装 conda 的稳妥步骤Linux 用户搜索“ubuntu 安装 conda”和“ubuntu 26安装conda”这类关键词的太多了。Ubuntu 下装 Miniconda 比 Windows 省心不少因为你要面对的不是 PATH 问题而是官方源下载速度极慢、以及后续 shell 配置激活的问题。我这里给一套我自己在 Ubuntu 20.04 / 22.04 上反复用过的流程# 1. 下载 Miniconda 安装脚本建议先到官网确认最新版本号 wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh # 2. 运行安装脚本 bash Miniconda3-latest-Linux-x86_64.sh # 3. 一路回车 yes安装在默认路径 ~/miniconda3 # 最后一步会问是否执行 conda init选 yes # 4. 重新加载配置文件 source ~/.bashrc # 5. 验证 conda --version这里有一个重要细节安装脚本最后问 Do you wish the installer to initialize Miniconda3 by running conda init? 时默认是 no。如果你手快按了回车没看到安装完会发现 conda 命令不存在。这时候不用重装手动执行一次~/miniconda3/bin/conda init bash source ~/.bashrc如果你用的是 zsh就把bash换成zsh。这条经验是我在给别人远程调试环境时被问过最多的问题之一其实 install 完先跑 conda init 是最顺的路径。至于“conda init 之后显示 no change”在 Linux 上也常见原因和 Windows 上一样——配置已经写过一次了但你是在没重开终端的情况下敲的 conda所以仍然无效。记住改完 shell 配置之后重开终端永远是最保险的第一步。3. 虚拟环境的生命周期创建、激活、删除与迁移3.1 为什么非要建虚拟环境我一上来就把所有包装在 base 里不行吗可以但你会后悔。base 环境是 conda 的根环境装完 Miniconda 或 Anaconda 之后base 里默认带了一整套 Python 和基础包Anaconda 带的尤其多。很多人图省事conda install xxx不带-n参数全装进 base。短时间看着没问题时间一长你会发现项目 A 要 pandas 1.5项目 B 要 pandas 2.0全装 base 里必然冲突conda 为了解析依赖会陷入永无止境的 solving environment。你想升级某个包但它是另一个项目的运行前提一升级那个项目就崩。哪天你删 base 或者重置 base所有环境一朝清零。所以正确的习惯是每个项目建一个独立环境环境之间物理隔离。我在本地机器上的习惯是base 永远保持干净只装 conda 和极少数的管理工具比如 mamba所有的项目依赖都放进独立环境里。3.2 最基本的增删改查命令一次说清# 创建新环境指定 Python 版本 conda create -n myproject python3.10 # 创建环境的同时安装一批包 conda create -n myproject python3.10 numpy pandas requests # 激活环境 conda activate myproject # 退出当前环境回到 base conda deactivate # 列出所有环境 conda env list # 删除环境加 -y 跳过确认 conda remove -n myproject --all -y # 从 environment.yml 创建环境团队协作最常用 conda env create -f environment.yml # 导出当前环境到文件 conda env export environment.yml这里提一个值得反复强调的细节conda create -n的时候可以不加 Python 版本conda 会默认用一个当前可用的版本。但建议你每次都显式指定版本比如python3.10。原因很简单很多包的兼容性跟 Python 版本强相关你不指定哪天不同项目创建的环境 Python 版本不一致依赖解析的结果也会不同容易埋坑。而且显式指定版本后conda 的 solver 会更快因为候选范围缩小了。3.3 删除环境之后残留文件怎么办热搜词里有“conda删除虚拟环境”。大部分人执行完conda remove -n xxx --all就以为万事大吉其实环境目录通常残留在~/miniconda3/envs/xxxWindows 上是C:\Users\你的用户名\miniconda3\envs\xxx。conda remove --all正常情况下会把这个目录删掉但偶尔由于文件占用比如某个 Python 进程还开着或权限问题会删不干净。遇到这种情况先确认没有进程在使用该环境的 Python然后手动删除目录。普通人不会经常遇到这种问题但一旦遇到别慌这是正常的。还有一个小细节删除环境前如果这个环境被 Jupyter kernel 注册过删完环境后jupyter kernelspec list里可能还会显示残留内核需要手动删jupyter kernelspec remove xxx这个坑我是真实踩过的做完环境清理后临时 kernels 还在导致别人连过来时一脸懵。3.4 环境迁移Linux 上装好的东西怎么挪到 Windows热搜词里有一条特别有意思“conda linux离线迁移到windows”。说实话跨平台的 conda 环境迁移我一直不建议用 environment.yml 去硬导因为不同平台默认源不同包版本解析结果也不同很多包在 Linux 上能装在 Windows 上根本不存在比如某些源码包依赖编译工具链。如果你真的要在离线状态下把 Linux 环境搬到 Windows我给两种思路第一种如果你只是要“相同的包版本”用conda env export --from-history导出这个命令只导出你显式安装的包和版本不带依赖树的哈希到 Windows 上重新建环境、装包最终版本大概率不一致但主要依赖可控。第二种如果是严格的“二进制一致”真正的做法不是 conda 去迁移而是用 Docker 把你的 Linux 环境打包成镜像在 Windows 上用 WSL2 跑 Docker。这属于曲线救国实际工作中比较常见。另外还有个工具叫 conda-pack它能把环境打包成一个 tar.gz解压即用适合同平台之间离线分发的场景。但请注意conda-pack 打包的环境在解压机器上不一定能直接用因为环境里的 prefix 路径是写死的你需要在目标机器上重新设置CONDA_PREFIX或者其他变量。说实话它更适合运维侧的离线部署不适合开发者的日常环境复制。4. 安装包老卡住solving environment、MemoryError 和换源全解析4.1 为什么一执行conda install就长时间卡在 solving environment这个可能是我见过最多人提问的场景之一。完美的热搜词命中conda中安装库一直卡在solving environment。什么是 solver简单讲conda 在装任何包之前会先读取你当前环境里所有已安装包的元数据然后和你要安装的新包联合起来寻找一组满足所有依赖约束的版本组合。默认的 solver 是经典求解器classic solver它是通过 SAT 求解器来枚举所有可能组合的当环境里包很多的时候组合爆炸求解时间从几十秒到几十分钟都有可能。我自己的体验是当你 base 环境里塞了 100 多个包再执行conda install一条新包求解过程出现 10 分钟以上的等待是很正常的。这时你以为是卡死其实它是在暴力求解。解决思路有三个层次。第一层增加超时时间或者耐心等待。但这个体验太差不推荐。第二层换用更快的求解器。conda 从 23.10 版本开始把 libmamba 作为默认 solver 的实验性支持你可以在你的 conda 配置里开启conda config --set solver libmambalibmamba 是 C 实现的求解器求解速度比经典 solver 快一个数量级以上。我实际感受是之前经典 solver 要 3 分钟的环境libmamba 基本 5 秒内出结果。强烈建议所有还剩经典 solver 的人切过去。第三层也是最重要的治本减少环境的体量。一个环境里装 200 个包conda 的 solver 永远快不了。合理做法是环境里只放那个项目真正需要的包能用 pip 装的纯 Python 包就尽量用 pip 装后面我会讲 conda 和 pip 的边界别让 conda 去解析那些纯 Python 的依赖树。4.2 MemoryError: The conda process ran out of memory 怎么破热搜词里有这么一条“conda memoryerror: the conda process ran out of memory. increase system memor”。这在 Windows 上出现的概率远高于 Linux。原因是 conda 的 solver 在处理大依赖树时需要大量内存默认的最大内存上限可能不够或者系统内存本身紧张。最简单的调整方式是在环境变量里设置# Windows 设置 conda 最大内存 set CONDA_MEMORY_LIMIT8GB这是 conda 从 23.x 版本开始支持的配置项。如果设完还是报 MemoryError优先考虑两条路一是换 libmamba solver上面写过二是把你这个环境里不需要的包清理掉再装新的。还有个小技巧如果你只是要临时装一个不重要的包并且不太在意版本精细度可以尝试conda install --freeze-installed这个参数会让 conda 不更新环境中已有的包只求解新增包依赖树范围小很多内存和耗时都能降下来。4.3 conda 换源选哪个源怎么换为什么换了还慢“conda换源”、“conda最新镜像源”、“conda国内镜像源”这几个热搜词背后其实是同一个痛点官方源在国外下载速度太慢。国内常见的镜像源有清华 TUNA、阿里云、中科大等。这里我不点名说哪个“最新”因为镜像地址更新很频繁我更建议你掌握换源的原理这样以后不管网址怎么变都能自己搞定。conda 的源配置写在.condarc文件里。Windows 用户路径通常是C:\Users\你的用户名\.condarcLinux 用户是~/.condarc如果文件不存在就新建一个。最简配置格式是channels: - defaults show_channel_urls: true想换成清华源你在终端里直接运行conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ conda config --set show_channel_urls yes国内镜像源曾经出过一个坑老版本镜像地址很多已经失效或迁移网上搜索到的一堆教程里写的链接根本打不开。所以我的建议是不要刷教程去镜像站的官网页面看当前最新地址然后手动写进.condarc。关于“conda 最新镜像源”这个话题我想多啰嗦一句很多人换完源之后发现下载速度依然很慢原因是 conda 安装包时还会访问repodata.json如果你的.condarc里写了多个 channel而且其中一个不稳定conda 会等它超时后再去下一个 channel这个等待过程非常折磨人。解决办法是尽量只留一个 channel 为默认别叠一堆源。另外有一种更优的思路如果你所在环境访问国外网络本身不慢那其实根本不需要国内镜像源。大家的痛点主要在于大体积的 conda 包比如科学计算库动辄 100MB如果网络条件允许开着系统代理直连 defaults 反而不容易遇到源同步延迟导致的“找不到包”。我自己在有两台机器一台走清华源一台走 defaults日常体验其实差别不大。这个就看个人网络环境了。4.4 实在不想用镜像源有什么硬核方案热搜词还有一条“conda 不用镜像源”挺有意思。说实话如果你因为版权、安全或者网络原因完全不想用任何第三方镜像又嫌官方源慢我提供几个方案下载.tar.bz2或.conda包本地安装conda install /path/to/package.conda这种离线包可以在官方网站下载然后用 conda 从本地文件安装不经过任何通道。适合网络极差或内网部署场景。使用 Miniforge 直接换到 conda-forge 通道。Miniforge 默认就走 conda-forge特别适合需要大量开源包、又不希望版权上有任何纠结的场景。关于 Miniforge 和版权问题的细节我放在后面章节专门展开。用 mamba 或 micromamba 代替 conda 来加快下载和求解。mamba 在解决依赖时用的库不同速度会快不少。这些方案各有各的适用场景不是每条路都适合所有人但至少可以让你在“不用镜像源”的前提下把 conda 用得舒服。5. conda install 与 pip install边界、混用与避坑5.1 它们到底哪里不同这是热搜词里被问爆了的一个问题。我直接从三个层面拆开讲。第一包来源。conda 安装的包来自 conda channel比如 defaults、conda-forge这些通道里的包很多是经过 conda 团队或社区重新编译打包的自带非 Python 依赖比如 C 库、二进制动态库。而 pip 安装的是 PyPI 上的 wheel 包或源码包更纯粹地只面向 Python系统级的依赖库里很多不打包需要靠你的系统自己装。第二依赖解析。conda 会检查一个包背后的完整依赖树包括非 Python 的二进制库所以它很慢但更完整。pip 默认只解析 Python 包依赖不会管你系统里有没有那个动态库因此在某些科学计算场景会装完直接 import 报错。第三环境管理。conda 自己管理环境可以指定 Python 版本。pip 只是“往当前解释器里装包”它本身没有任何环境隔离概念。所以“conda 和 pip”不是二选一而是互补关系用 conda 管好 Python 版本和环境用 pip 补装 conda 通道里没有的包。最直观的例子是你在 conda 环境里装 PyTorch官方写的是pip install torch torchvision torchaudio但你在 conda 里执行这种命令前真的建议先 conda 装好 CUDA 相关的依赖再用 pip 装 torch后者的依赖解析才能找到系统库。5.2 混用时的秩序问题很多人问既然两个都能装包那我到底用哪个装答案不是唯一的但我给一个自己一直遵守的铁律创造环境永远用 conda因为要管理 Python 版本。环境内基础库优先用 conda 装尤其那些有二进制后端的库比如 numpy、scipy、pandasconda 安装的版本与系统的兼容性更好。其他纯 Python 包或者 conda 通道没有的用 pip 装。这里有个大坑千万不要在同一个环境里交叉反复地 pip install 和 conda install。因为两者生成的依赖元数据各自维护conda 并不知道你 pip 装了哪些包pip 也不知道 conda 的依赖约束。交叉安装的次数多了环境的一致性就没法保证最终可能看起来一切都正常某天你conda install一个新包时conda 求解器检测到和 pip 已装包冲突直接给你报错甚至回滚掉你 pip 装的东西。如果实在避免不了混用有一个常规操作可以缓解先 pip install 的包尽量少而精装完立刻conda env export保存现场一旦出问题可以快速重建。另外pip 装包时记得用python -m pip而不是裸pip这样能保证 pip 确实是当前环境对应解释器的 pip避免装到 base 环境去。6. conda 在真实场景里的整合玩法VSCode、JupyterLab、GPU 与进阶工具6.1 VSCode 怎么识别 conda 环境搜索“vscode使用conda环境”、“vscode中链接conda终端”、“vscode配置conda”这类关键词的人基本都是想用 IDE 写代码结果发现解释器选不对。VSCode 用 conda 环境分两步先选解释器CtrlShiftP输入 Python: Select InterpreterVSCode 会列出它扫描到的所有 Python。由于 conda 环境的 Python 都在~/miniconda3/envs/xxx/bin/python.exeWindows或~/miniconda3/envs/xxx/bin/pythonLinux只要你安装了 Python 插件它一般能自动识别。识别不到的点“Enter interpreter path”手动填路径。再让终端进入该环境VSCode 终端默认走系统的 shell而不是 conda 环境。你想打开终端就自动 activate 某个环境可以在.vscode/settings.json里配置{ terminal.integrated.profiles.windows: { PowerShell: { source: PowerShell, args: [-NoExit, -Command, conda activate myproject] } } }不过说实话我更推荐的做法是不配这个——终端里手动敲conda activate myproject就完了简单直接。重点是要让 VSCode 的解释器选中这个环境终端进去后也确认下python --version和which python是否指向那个环境的路径。6.2 JupyterLab 打开的常见问题SSL、内核与网页版热搜词里有两条特别具体“conda怎么打开网页版jupyter”、“win11 conda 配置jupyterlab 提示ssl.sslerror {asn1: not_engou} not engou”这条被输入截断了一半但能看出是 SSL 相关 ASN1 错误。先回答最简单的在激活某个环境后执行jupyter lab终端会打印一串 URL其中包含一个带 token 的本地地址用浏览器打开即可。如果你希望 Jupyter 能识别不同的 conda 环境内核需要安装ipykernel然后在对应环境里执行conda install ipykernel python -m ipykernel install --user --name myproject --display-name Python (myproject)这样每次打开 Jupyter新建 Notebook 的时候就能在 Kernel 菜单里看到你的环境。关于 Windows 11 上配置 JupyterLab 遇到 SSL 报错这种问题本质上是 OpenSSL 版本或证书链的问题不是 conda 本身的问题。但有一个经典原因conda 环境里的 OpenSSL 版本过高或过低和 Jupyter 的 websocket 加密连接不兼容。我的排查思路是分三步走先看报错是发生在浏览器访问时还是 Jupyter 启动时如果是启动阶段在 Python 里检查环境和版本可以用conda list openssl看 openssl 版本升级或降级后再试如果升级 openssl 没用就查看是否系统代理干扰了本机回环请求。还有一个更省事的方案直接用 VSCode 写 Jupyter Notebook把 Jupyter 服务器拉到 VSCode 里面跑少一层浏览器的 SSL 日志干扰问题往往就不见了。6.3 手把手搞定 TensorFlow-GPU 环境的版本匹配关于“手把手教你用conda搞定tensorflow-gpu环境(附版本对照表)”这个主题我太熟悉了。很多人在这一步翻车基本都是因为版本对应关系混乱TensorFlow 版本、Python 版本、CUDA 版本、cuDNN 版本四个维度只要有一个不匹配import tensorflow 就会报错。这里我给一个我在本地机器上实测过很多次的稳定组合参考组件推荐版本截止 2024 年初一个稳定的组合Python3.10TensorFlow2.12 或 2.13CUDA11.8cuDNN8.6创建命令如下conda create -n tf_gpu python3.10 -y conda activate tf_gpu conda install cudatoolkit11.8 cudnn8.6 -y pip install tensorflow2.12注意这个组合不是“唯一正确”的答案。因为 NVIDIA 驱动、系统 CUDA 驱动、conda 包通道的变化版本映射关系会变。最稳妥的办法是去 TensorFlow 官网查看当前官方测试过的版本对应表然后利用nvidia-smi查看自己的显卡驱动支持的最高 CUDA 版本再决定选择哪个 CUDA 版本。不要把驱动版本、conda 包里的 cudatoolkit 版本和系统级 CUDA 混为一谈——你 conda 里装的 cudatoolkit 只是运行时库它不需要与系统 CUDA 驱动完全一致但系统驱动必须满足最低版本要求。另外在某些 Windows 环境里TensorFlow 从 2.11 开始不再支持原生 Windows GPU。是的Windows 用户没法只用 pip 装 tf 2.11 来直接用 GPU。很多老帖子上装的是 2.10这是 Windows 原生 GPU 支持的最后一块拼图。后来也有人通过 WSL2 跑 Linux 版的 TensorFlow这也是一条路径但不在本文展开。6.4 用 conda 装 Xinference 等大模型推理框架的注意事项热搜词里“conda安装xinference”出现了多次。Xinference 是一个大语言模型推理框架它依赖非常重尤其是不同模型需要不同的推理后端pip 装体积很大。我的建议是专门为它建一个独立环境原因很简单Xinference 的依赖树里有很多库会和你的日常数据处理库冲突直接装进你平时用的数据分析环境几乎必然破坏现有依赖。做法如下conda create -n xinference python3.10 -y conda activate xinference pip install xinference[all]注意Xinference 官方推荐用 pip 安装conda 通道里没有正式的包。用 conda 只负责建环境、配 Python 版本实际依赖还是 pip 管。这就是我上面说的互补关系的最典型案例。6.5 Miniforge、conda-forge 与版权问题这是个很容易被人忽略但实际很重要的点。Anaconda 商业版在 2020 年开始调整了 ToS公司员工数量超过一定规模并且不是非营利组织或学校的情况下使用 Anaconda 的默认源defaults需要购买商业授权。个人开发者无所谓但如果你在公司环境里大规模使用 Anaconda你的法务部门可能会找上你。解决思路就是热搜词里提到的使用 conda-forge 或 Miniforge。Miniforge 是一个社区维护的、基于 conda 的最小化发行版它默认配置的 channel 是 conda-forge这是一个由社区驱动、相对宽松的频道没有 Anaconda 商业授权的限制问题。安装方式基本和 Miniconda 一样只是下载地址不同。我自己有两台开发机一台装了 Miniconda 用 defaults个人项目一台装了 Miniforge 走 conda-forge公司项目。切换后的最大感受是conda-forge 上有非常多 defaults 里没有的包有些包甚至更新时间比 defaults 还快比如一些科研向的冷门库。缺点则是 conda-forge 的包一致性维护非常严格某些包求解时间反而长一些不过 libmamba solver 把这个体验拉回来了。6.6 conda 和 uv新工具来了旧工具还有没有必要学这个热搜词条直指一个新趋势uv一个用 Rust 写的极快的 Python 包管理工具。它在 PyPI 生态里异常火爆主打“快到你怀疑人生”。很多人开始纠结既然 uv 这么香那我还有必要学 conda 吗我的观察是it depends。uv 主要解决的是 pip 层面的效率问题它也能做虚拟环境管理但它不解决系统级依赖CUDA、MKL的安装问题和 pip 一样它只关心 Python 包不关心你系统里的动态库。而你用 conda 的很大一个理由恰恰是 conda 能同时装好二进制依赖并保证环境内的一致性。你完全可以组合使用conda 维护 Python 版本和系统级库cudatoolkit、mkl、ffmpeg 这类uv 负责 Python 包的超快速解析和安装。我个人的真实习惯已经演变成conda 建环境uv pip install 装包。这样做的好处是conda 帮你锁住系统级依赖uv 帮你加速 Python 包的安装两边各管各的彼此不冲突。但请注意我把 uv 当作 pip 的替代品而不是混着用——如果你两个都在环境里装包同样会有元数据不一致的问题。6.7 环境列表用命令行怎么查Linux 系统下用 conda 命令查虚拟环境列表最简单的方式conda env list或者conda info --envs这两个命令等价。如果要看某个环境里具体装了哪些包conda list -n myproject如果想看当前激活环境的包列表直接conda list。这条热搜词虽然简单但被搜索的次数非常多我猜可能是因为很多人刚接触 conda 时看教程说“执行 conda env list 查看环境”结果把env和list的关系搞混敲成conda list env。这里注意了conda list的命令参数是包相关的语义跟环境列表没有直接关系别拼错了。7. 我的 conda 使用习惯几条不谈技术细节但很救命的心得最后不做什么总结了就聊几条我这几年养成的习惯希望能帮你少走点弯路。第一条新电脑装 Python 环境我永远先装 Miniconda而不是 Anaconda。Anaconda 自带几百个包听着方便其实大部分你根本用不到还会拖慢 conda 的 solver 速度让每次 install 都变慢。Miniconda 只有 conda、Python 和极少的系统依赖从零开始装项目需要的包环境清爽排查问题也容易。等到你真的发现自己需要 Anaconda 那几十个默认包时多半已经知道自己在干什么了不需要靠 Anaconda 的那套全家桶去兜底。第二条环境命名要带项目语义不要用 python3、test123 这种容易混淆的名字。我的一般规则是数据分析就用>conda env export environment.yml不过要注意conda env export默认会导出大量精确到哈希的依赖恢复时不一定能在其他平台复现。如果你只是给其他开发者提供一个能用的还原入口我更推荐conda env export --from-history这个命令只导出你显式指定过的包没了依赖树的深层哈希在其他机器上重建环境时conda 会重新解析依赖兼容性更好。说实话这个技巧网上很少有人提但它对我实际帮同事恢复环境时帮了大忙。第四条遇到 conda 的诡异问题先做两个检查——看 conda 版本再看 solver 类型。很多问题在升级 conda 到最新版、切到 libmamba solver 之后自动消失了。如果你还卡在很老的 conda 版本上别急着去搜具体的报错信息先把 conda 本体升上去conda update conda -n base然后再试大概率很多玄学问题都没了。第五条也是最后一条不要怕 conda 慢就弃用要学会“换工具”而不是“硬等”。当你直觉觉得某个环境装东西越装越慢、越装越乱最省心的操作是直接删掉这个环境重开一个干净的用--from-history导出的清单重新装一遍。一个从零开始的环境往往比一个修修补补的环境稳定得多这跟你重装系统一个道理。我在过去几个月里已经不止一次靠“删掉重来”解决了连官方 issue 都说不清的环境病。conda 这东西本质上就是一个帮你管理“混乱”的工具。用得好它让混乱保持在可控范围用得不好它自己也能变成另一个混乱源头。希望这篇偏实战经验的分享能给你一些参考。如果你也有什么 conda 相关的翻车现场欢迎在评论区分享出来说不定下一个被大家高频搜索的疑难杂症就是从你这条评论里面抽出的关键词。
