前几天把工作机和实验室工作站上的 Anaconda 全部从默认源切到了交大源SJTU最直观的变化是conda install的输出从几十 KB/s 的龟速变成了几 MB/s 的连续滚屏一个带 mkl 的 numpy 环境从泡杯咖啡回来还在 Downloading变成了去倒杯水就建好了。这不是什么玄学优化只是把包的获取地址从跨洋链路换到了同城链路但收益非常实在。这篇东西写给三类人看一是刚装完 Anaconda 还在用默认源、被 solver 和下载速度折磨的同学二是环境已经能跑、但每次重建环境都像开盲盒的老用户三是用 PyCharm、VS Code 写 Python需要把 conda 环境和编辑器打通的人。整篇会围绕 conda 源的配置层级、.condarc的真实写法、缓存清理、pip 源联动、PyTorch 安装路径选择、PyCharm 关联这几件事展开中间会穿插我自己踩过的坑和一些反直觉的细节。1. 换源这件事到底解决了什么麻烦1.1 默认源慢的根因不在你的网速很多人第一反应是我家宽带不行其实跟带宽关系不大。Anaconda 默认的 channel 指向repo.anaconda.com物理位置在境外从国内访问要跨越多跳路由TCP 握手和 TLS 握手本身的往返时间就已经不短了。更麻烦的是 conda 的工作方式它在 solve 依赖之前会先拉取repodata.json这个文件在 main channel 里体积不小而且不是拉一次就完事每次环境操作都可能触发一次过期检查过期就重新下载。所以你会观察到两个典型现象先是Solving environment卡很久那是它在下载和解析索引然后是Downloading and Extracting Packages阶段单个大包比如 numpy、mkl、pytorch的吞吐量上不去。前者是延迟敏感后者是吞吐敏感跨洋链路两头都吃亏。换成国内镜像源之后索引拉取从秒级到十几秒变成毫秒级响应大包下载从单连接爬行变成能跑满带宽这才是体感变化的来源。还有一点容易被忽略conda 默认会对索引做本地缓存缓存里有绝对 URL。这意味着你改了配置以后如果不清缓存conda 可能还在按缓存里的旧地址去下载看起来就像改了没用。1.2 交大源SJTU值得选的几个理由国内可用的 Anaconda 镜像源不止一个我最后把主力配置放在交大源上主要基于这几点权衡。第一是目录结构规范。SJTU 镜像站按/anaconda/pkgs/main、/anaconda/pkgs/r、/anaconda/pkgs/msys2、/anaconda/cloud/xxx这样的路径组织和 conda 官方 channel 的映射关系非常清晰配default_channels和custom_channels的时候不容易写错。这一点比某些只挂了部分目录的镜像站省心很多。第二是覆盖范围完整。除了pkgs/main这种核心目录conda-forge、pytorch、nvidia 这些第三方 channel 通常也有对应的 cloud 目录配好之后-c pytorch这样的命令会自动走镜像不用每次手动拼 URL。第三是同一个站还能顺带解决 PyPI。写 Python 的人不可能只装 conda 包pip 源和 conda 源指向同一个站点排障的时候只需要怀疑一个地方心态会好很多。提示任何镜像站都有同步延迟和维护窗口。配镜像不等于把自己的路堵死配置里保留临时切回官方源的能力出问题时才好定位。这一点后面讲排查的时候会具体说。2. 动手之前先把配置层级和文件位置搞明白2.1 conda 的配置其实有四个来源很多人改源改不明白根源在于不知道 conda 到底读了几处配置。它按优先级从高到低读取四种来源命令行参数比如-c、--override-channels、环境变量、.condarc配置文件、以及 conda 自带的默认值。.condarc本身又分用户级和系统级用户级优先级更高。想一眼看清楚到底读了哪些文件就用这条命令conda config --show-sources输出里会列出每一个被读取的配置文件路径和其中的键值。如果这条命令的输出里只有系统级的配置、没有你刚编辑的那个文件那说明你的文件根本没被读到后面所有的改了不生效都是从这里开始的。养成习惯任何 conda 配置相关的怀疑先跑这一条。2.2 .condarc 到底在哪Windows 用户最容易在这翻车各平台的位置如下直接对照着找平台用户级配置路径系统级配置路径WindowsC:\Users\用户名\.condarc安装目录\.condarcmacOS~/.condarc安装目录/.condarcLinux~/.condarc安装目录/.condarcWindows 上最高频的翻车方式是用记事本保存文件结果变成了.condarc.txt。资源管理器默认隐藏已知扩展名你在列表里看到的就是.condarc看起来完全正常但 conda 读不到。解决办法是先在查看里打开文件扩展名然后重命名去掉.txt。验证方法还是上面那条conda config --show-sources如果输出里没有你编辑的路径就回头检查扩展名。第二个坑是 YAML 格式。.condarc是 YAML缩进必须用空格绝对不能混 Tab冒号后面要有一个空格字符串不需要引号但用了也行别用中文全角引号。这些都写对了文件才可能被正确解析。如果 conda 报 YAML 解析错误通常是缩进或者特殊字符的问题逐行对着空模板抄一遍最快。2.3 channels、default_channels、custom_channels 到底谁管什么这三个键是换源的核心但名字太像很多人配了半天其实只改了对速度影响最小的那个。逐个说清楚。default_channels定义的是defaults这个虚拟 channel 实际指向哪些地址。关键点在于defaults只是一个别名它的真实内容由default_channels决定。如果你只在channels里加了镜像地址却没动default_channels那么当配置里存在- defaults时conda 依然会去官方源找包。这是我明明加了镜像怎么还是慢的头号原因。channels定义的是搜索优先级顺序列表越靠前越优先。用conda config --add channels添加时新项会被插到列表最前面而不是追加到末尾这个行为和很多人的直觉相反。custom_channels则是把某个 channel 名称映射到一个基础地址上。比如把pytorch映射到镜像站的 cloud 目录之后你执行-c pytorchconda 就会去镜像上找而不是去官方 pytorch channel。这个键能省掉很多每次手写完整 URL 的麻烦。3. 手把手把 Anaconda 切到交大源3.1 最快路径四条命令先跑通如果你只想快速见效先用命令行把核心目录加上conda config --add channels https://mirrors.sjtug.sjtu.edu.cn/anaconda/pkgs/main conda config --add channels https://mirrors.sjtug.sjtu.edu.cn/anaconda/pkgs/r conda config --add channels https://mirrors.sjtug.sjtu.edu.cn/anaconda/pkgs/msys2 conda config --set show_channel_urls yesmsys2这个目录是给 Windows 提供 Unix 风格命令行工具的Linux 和 macOS 上可以从这组命令里删掉。show_channel_urls: true的作用是让 conda 在下载时打印出每个包的完整来源 URL这是验证换源是否成功最直接的手段建议一直开着。这种写法的优点是快缺点就是前面说的它只改了channels没有动default_channels。如果你的配置里还留着defaults官方源依然是候选之一solver 有可能绕开镜像去官方找。所以真正推荐的做法是下面这种。3.2 推荐做法直接写一份完整的 .condarc把用户目录下的.condarc用编辑器打开没有就新建写入下面这份模板。这套内容覆盖了核心目录和几个常用的第三方 channelchannels: - defaults default_channels: - https://mirrors.sjtug.sjtu.edu.cn/anaconda/pkgs/main - https://mirrors.sjtug.sjtu.edu.cn/anaconda/pkgs/r - https://mirrors.sjtug.sjtu.edu.cn/anaconda/pkgs/msys2 custom_channels: conda-forge: https://mirrors.sjtug.sjtu.edu.cn/anaconda/cloud pytorch: https://mirrors.sjtug.sjtu.edu.cn/anaconda/cloud pytorch-lts: https://mirrors.sjtug.sjtu.edu.cn/anaconda/cloud nvidia: https://mirrors.sjtug.sjtu.edu.cn/anaconda/cloud bioconda: https://mirrors.sjtug.sjtu.edu.cn/anaconda/cloud simpleitk: https://mirrors.sjtug.sjtu.edu.cn/anaconda/cloud menpo: https://mirrors.sjtug.sjtu.edu.cn/anaconda/cloud show_channel_urls: true channel_priority: strict ssl_verify: true几个点需要说明。channels里只留defaults是刻意的因为defaults已经被default_channels重定向到镜像上了写法上更简洁也不会出现同一个包在两个条目里重复搜索的情况。custom_channels里的这些子目录不一定每时每刻都在同步尤其是比较少人用的 channel。判断方法很简单把地址粘到浏览器里看一下是否可访问返回 404 就把对应那一行删掉不影响其他部分。保守一点的做法是只保留conda-forge、pytorch、nvidia这三个其他按需再加。channel_priority: strict的含义是严格按channels的顺序挑包高优先级 channel 里有这个包就绝不从低优先级拿。好处是能有效避免同一个包从多个源混装坏处是偶尔会因为高优先级源缺少某个特定版本而报找不到包。新版 conda 默认已经是 strict我个人的体验是对于稳定的项目环境strict 带来的可复现性远比灵活拼包更值。注意改完.condarc之后不要立刻开始装包先跳到 3.4 节做验证。脚本写对了但配置没被读到是我见过最多的白折腾一小时。3.3 清缓存这一步千万别省配置改完之后必须清一次索引缓存conda clean -i-i是清 index cache也就是那些repodata.json缓存。前面说过索引缓存里存的是绝对 URL旧缓存里全是官方源地址。不清它conda 可能继续按旧地址去请求你的新配置看起来就完全没生效。这个坑非常隐蔽因为命令不报错、只是慢很容易被误判成镜像站不行。顺手可以把包缓存也清一下尤其是磁盘紧张的时候conda clean --all这条会把 tarball 缓存、未使用的包、索引缓存一起清理掉通常能回收几个 GB。我一般在换源后清一次之后每隔一两个月清一次。清理的代价是下次装包要重新下载但在换源场景下重下本来就比留着旧缓存快。3.4 怎么确认真的生效了配置验证分两层先看配置本身再看实际请求。第一层看配置有没有被正确读取conda config --show-sources conda config --show channels conda config --show default_channels第一条会列出所有被读取的配置文件后两条分别打印当前的 channel 列表和 defaults 的实际指向。如果default_channels打印出来还是repo.anaconda.com说明你的文件没被读到回到 2.2 节检查路径和扩展名。第二层看实际下载走的是哪里。随便建一个小环境conda create -n src_probe numpy -y因为开了show_channel_urls输出里会打印每个包的完整 URL。看到https://mirrors.sjtug.sjtu.edu.cn/...就算成功了。也可以不建环境用 dry-run 看conda install -n base --dry-run numpy看输出的 URL 前缀即可。验证完记得把探测环境删掉conda env remove -n src_probe3.5 pip 源也要一起换掉conda 源改好只解决了一半问题。很多包尤其是比较新的、conda 上没有的只能用 pip 装pip 有自己的索引配置跟 conda 完全是两套。用 pip 自带的配置命令改不要手工去编辑 ini 文件pip config set global.index-url https://mirror.sjtu.edu.cn/pypi/web/simple pip config list第二条件命令会把当前生效的配置打印出来确认写入成功。配置文件的位置Linux 和 macOS 上是~/.config/pip/pip.confWindows 上是%APPDATA%\pip\pip.ini。如果想知道 pip 到底读了哪些文件用pip config debug它会列出所有候选路径和每个路径的存在状态排查改了不生效时很有用。临时想用某个源装单个包命令行指定即可python -m pip install requests -i https://mirror.sjtu.edu.cn/pypi/web/simple这里我习惯写成python -m pip而不是直接pip。原因是机器上可能装了多个 Pythonpip命令指向的未必是当前 conda 环境里的那一个。用python -m pip能保证当前解释器是哪个就往哪个环境装这个习惯能省掉大量包明明装了却 import 不到的困惑。4. 换源之后的实战建环境、装 PyTorch、挂 PyCharm4.1 建一个干净的虚拟环境我的习惯是 base 环境只用来管理 conda 自身所有项目依赖都放在独立环境里conda create -n dl python3.11 -y conda activate dl python -VWindows 上用where pythonLinux 和 macOS 上用which python确认当前解释器确实在envs/dl目录下而不是系统 Python 或 base。这一步值得养成肌肉记忆很多依赖装了但没生效的问题追到最后都是环境激活错了。指定 Python 版本时建议写死小版本比如python3.11而不是python3。写死版本能让 solver 少走很多弯路求解时间明显下降。同理安装任何包时如果能确定版本就把版本号带上numpy1.26比numpy快得多。实操心得环境名带上用途和 Python 版本比如geo-py311、web-py310几个月后回头看目录列表时你会感谢自己。纯靠env1、env2命名到最后谁也不敢删。4.2 装 PyTorch 的两种路径怎么选PyTorch 是这个场景下最典型的大包也是最能体现换源收益的。有两条路。第一条是 conda 路径。因为我们把pytorch和nvidia映射到了镜像的 cloud 目录所以可以直接写 channel 名conda install pytorch torchvision torchaudio pytorch-cuda12.1 -c pytorch -c nvidia注意pytorch-cuda的版本号要和你的显卡驱动匹配装之前先用nvidia-smi看驱动支持的 CUDA 上限别硬套别人的命令。这条路的好处是依赖由 conda 统一管理和 numpy、mkl 这些底层库的兼容性有保障。第二条是 pip 路径。CPU 版本最简单python -m pip install torch torchvision torchaudio因为 pip 源已经指向了镜像这条命令会直接从镜像拉 PyPI 上的 wheel速度很快而且不用操心 solver。GPU 版本需要明确指定官方的 wheel 索引python -m pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121这里要提醒一句--index-url会覆盖掉你配置的 PyPI 镜像走的是官方 wheel 索引速度取决于当时的链路情况。如果只是想要某个 CUDA 版本的 wheel另一个思路是先用浏览器把.whl文件下下来再python -m pip install 文件名.whl本地安装这样下载过程可以走你自己的下载工具。装完必须验证三行代码搞定import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))第三条只在cuda.is_available()为True时才能执行如果前一条返回False说明装的还是 CPU 版本或者驱动版本不匹配。4.3 让 PyCharm 用上这个 conda 环境PyCharm 关联 conda 环境本身不复杂但细节不对就会出现编辑器里飘红、终端里能跑的割裂状态。标准流程是打开File→Settings快捷键CtrlAltS→ 左侧展开Project→Python Interpreter→ 点右上角齿轮旁边的Add Interpreter→ 选Add Local Interpreter→ 左侧选Conda Environment→ 选Use existing environment→ 在下拉框里找到刚才建的dl。如果下拉框里没有你的环境就手动指定。把Conda executable指向 conda 主程序WindowsC:\Users\用户名\anaconda3\Scripts\conda.exemacOS / Linux~/anaconda3/bin/conda再把Interpreter指向环境里的 PythonWindowsC:\Users\用户名\anaconda3\envs\dl\python.exemacOS / Linux~/anaconda3/envs/dl/bin/python确认无误后回到主界面解释器列表里应该能看到 torch、numpy 这些包。如果列表是空的最大概率是解释器路径选到了 base 而不是dl。还有一个常见的割裂场景PyCharm 的设置里解释器选对了但底部 Terminal 里which python显示的还是系统 Python。原因是 PyCharm 的内置终端默认可能不自动激活 conda 环境。新版 PyCharm 在Settings→Tools→Terminal里有相关选项勾上自动激活就行。实在不想折腾在内置终端里手动conda activate dl也能用。4.4 顺手把包缓存和环境目录挪出系统盘conda 有两个很能吃空间的目录pkgs_dirs存下载的包缓存envs_dirs存所有环境。默认都在安装目录下Windows 上通常就是 C 盘。跑了一两年之后占掉几十 GB 是常态。在.condarc里加上这两项以后新建的环境和缓存就会落在你指定的盘pkgs_dirs: - D:\conda\pkgs envs_dirs: - D:\conda\envs这里有个重要限制改了envs_dirs之后已经存在的环境不会自动搬过去只有新建的才会用新路径。想搬旧环境正确做法是导出环境再重建conda env export --no-builds env_backup.yml conda env create -f env_backup.yml不建议直接剪切环境目录。环境里的脚本和部分元数据包含硬编码的绝对路径剪切之后大概率出各种奇怪的 import 错误。这也是为什么我更推荐每个项目一个独立环境——需要迁移时直接重建比修一个坏掉的环境省时间得多。5. 踩坑实录换源之后最容易撞上的问题5.1 问题速查表下面这些是我和周围人这几年实际撞过的按现象整理成表遇到问题可以直接对号。现象常见根因处理方式CondaHTTPError: HTTP 000 CONNECTION FAILED索引缓存里还是旧地址或配置里有明文 http 地址conda clean -i检查.condarc中所有 URL 是否都是 https改完配置速度毫无变化只改了channels没改default_channels且缓存未清补上default_channels再conda clean -i--show-sources里看不到自己的配置文件文件实际叫.condarc.txt或者 YAML 语法错误被跳过打开扩展名显示后重命名用 UTF-8 编码重写PackagesNotFoundError渠道顺序问题或镜像未同步该版本调整channels顺序临时用--override-channels -c指定单一源改用 pip 装Solving environment长时间无响应channel 数量太多索引体积大精简 channel指定精确版本号必要时换更快的 solver终端里conda命令找不到没有执行过conda init执行conda init bash或 zsh、fish重开终端PyCharm 里 import 报红终端能跑编辑器解释器选错核对 Settings 里的 Interpreter 路径指向目标环境的 pythonconda list里看不到 pip 装的包两套元数据体系分别用conda list和python -m pip list核对磁盘空间异常增长包缓存和旧 tarball 堆积conda clean --all每次开终端都自动激活 baseauto_activate_base为 trueconda config --set auto_activate_base false5.2 几个反直觉的细节关于包版本变化的隐性风险。换源之后你可能装到和以前不同的构建版本这会引发 API 层面的报错。举个我自己遇到过的例子某个环境下import一个库的某个子模块时报ImportError: cannot import name xxx本地代码一个字没改。排查下来是镜像同步的版本比原来新新版本里这个子模块被拆分或重命名了。遇到这种报错先别怀疑代码用conda list | grep 包名看看版本再到对应项目的更新日志里确认是否有 API 变更比闷头改代码高效得多。关于--override-channels的正确用法。这个参数的意思是忽略配置文件里的 channels只用我命令行指定的。当你怀疑是镜像缺少某个版本时可以用它来做对照实验conda create -n test_env numpy --override-channels -c defaults -y这样能快速判断问题出在镜像上还是出在配置上。关于 solver 的选择。老版本 conda 用的经典 solver 在依赖复杂时确实慢。新版本已经可以用 libmamba solver速度提升很明显conda install -n base conda-libmamba-solver conda config --set solver libmamba换完之后再跑一次依赖复杂的安装体感差别相当大。关于镜像站的维护窗口。镜像站偶尔会做同步维护这时候某些包可能暂时取不到。别急着把配置全删了重来先用--override-channels指定官方源验证一下是不是镜像的问题确认是镜像问题就等一会儿再试。把所有配置推翻重来往往会引入新的问题。关于跨平台的环境导出。conda env export导出的 yml 里会包含prefix字段和带 build string 的版本号直接拿去另一台机器上重建经常失败。分享给别人的时候把prefix那行删掉build string 也可以用--no-builds去掉。另外注意导出的channels段落里如果还是官方地址别人拿到你的文件重建时又会回到慢速源上记得一并换成镜像地址。6. 我现在的日常维护方式跑了一段时间之后我固定下来几个习惯没什么技术含量但确实省事。.condarc和 pip 的配置文件我会在云笔记里存一份注释版说明每一项为什么这么写。换电脑或者重装系统时直接抄不用再回忆当时那个 cloud 目录到底有几个。注释里我一般会写清楚哪些行是可以删的、哪些是必须的避免以后自己看不懂。base 环境我只留 conda、pip、conda-libmamba-solver 这几个其他一律不进 base。这条规则看起来苛刻但它保证了我任何时候重装 conda 都不会波及项目环境。环境导出这件事我改成了两套文件各存一份environment.yml用于跨平台交流conda list --explicit spec-file.txt用于同平台同架构的精确重建。前者可读性好后者装得出来两个一起放在项目根目录里过半年回头看也不会慌。诊断问题的第一反应永远是conda config --show-sources这条命令十分钟能省下我半小时。它回答的是最根本的问题conda 到底读了什么配置。配置读错了后面所有的操作都是建立在流沙上。最后说个我自己的小心得。换源这类配置看起来很机械但真正耗时间的从来不是敲命令而是配置改了却没生效时那种到底哪里不对的悬空感。所以我现在做任何配置改动都会在同一次操作窗口里把验证做完改完立刻清缓存清完立刻建一个小环境做端到端验证验证通过才去干正事。这一个动作能把绝大多数改了没生效的坑堵在发生之前。