Anaconda环境总在C盘？改envs_dirs与pkgs_dirs并迁移

1. 环境总往C盘跑，根子到底在哪

装完 Anaconda 敲下第一条conda create，看着进度条一点点爬到 100%，结果回车一看，新环境安安静静躺在了C:\Users\你的用户名\.conda\envs下面。C 盘本来就紧张，一个带 PyTorch 的环境动辄七八个 G，几个环境一叠，系统盘直接亮红灯。我第一次遇到这事的时候也是懵的：明明安装的时候选了别的盘，怎么建环境还是往 C 盘塞。后来把 conda 的配置体系摸了一遍才明白，Anaconda 创建 Python 环境默认 C 盘，根本不是安装路径决定的，而是由一份叫.condarc的配置文件里envs_dirs这个列表说了算，改路径的正解就是去动它。这篇东西写给两类人：一类是刚被 C 盘爆满警告弹窗吓到的新手，另一类是用了一两年 conda 但一直靠"手动剪切目录"硬扛、结果把环境搞坏过的老用户。我会把 conda 判断路径的完整逻辑、三种改法的取舍、已经建好的环境怎么无损搬家，以及我自己踩过的那些坑，一条一条摊开讲。

1.1 一次 conda create 背后发生的路径决策

很多人以为环境路径是在 Anaconda 安装时"烧"进去的，其实不是。当你敲下conda create -n myenv python=3.10这一行命令，conda 内部走了一遍挺严谨的决策链条：先看命令行里有没有显式指定的-p/--prefix，有就直接用，后面全部流程跳过；没有的话就去找envs_dirs这个配置项，它是一个有序列表，conda 会从第一个开始逐个检查，找到第一个"当前用户可写"的目录，就在那里建myenv文件夹。如果所有配置的目录都不可写，conda 才会退回到用户主目录下的.conda\envs兜底。

这就解释了一个特别常见的现象：你在.condarc里写了D:/conda/envs，但因为盘符拼错、目录没提前建好、或者那个目录被设成了只读，conda 判定不可写，默默回退到 C 盘，还不给你报错。所以排查"配置改了没用"这类问题，第一步永远是conda info看envs directories的实际列表，而不是盯着配置文件自我怀疑。

再补一个容易被忽略的点：envs_dirs的顺序有讲究。列表里排第一的可写目录就是默认落点，后面的只是"备胎"。如果你用--append而不是--add添加目录，新路径会被塞到列表末尾，前面那个 C 盘路径仍然是第一顺位，看起来配置生效了，实际一点用没有。这个细节坑过太多人，我在下面实操环节会专门说。

1.2 envs_dirs 与 pkgs_dirs 是两个口袋

.condarc里和磁盘占用相关的核心配置有两个，很多人只认识第一个：

• envs_dirs：环境目录。每个环境是一套完整的 Python 解释器加 site-packages，这里决定环境文件夹落在哪。
• pkgs_dirs：包缓存目录。conda 下载的每个包压缩包和解压后的内容都存这里，是全局共享的。

为什么两个都要改？因为 conda 装包的时候，会先把包缓存到pkgs_dirs，然后从中硬链接（hard link）文件到目标环境的site-packages。硬链接的本质是给同一份磁盘数据起两个名字，所以如果pkgs_dirs和envs_dirs在同一个磁盘分区上，一个包在磁盘上只占一份空间，装十个环境也只占一份。一旦跨盘符，Windows 的 NTFS 根本不支持跨卷硬链接，conda 检测到失败后会自动降级成"复制文件"，结果就是：包缓存占一份，每个环境再各占一份，磁盘用量直接翻倍，创建环境的时间也从几十秒变成几分钟。

所以我的实操建议很明确：envs_dirs和pkgs_dirs放在同一个盘、同一个父目录下，比如统一收到D:/conda/里面，一个envs一个pkgs。这样硬链接才能正常生效，这是"改路径"这件事里性价比最高的一条经验，比后面任何花哨操作都管用。

2. 动手前先想清楚的三件事

2.1 为什么只改 envs_dirs 常常不够

前面提了硬链接的事，这里再展开一层。我见过不少人的做法是：把envs_dirs改到 D 盘，然后发现.conda\pkgs那个文件夹照样蹭蹭涨，一路涨到十几个 G，于是又开始怀疑人生。原因就是pkgs_dirs还在默认位置——conda的包缓存默认跟随安装位置，通常在用户目录下，跟环境路径完全是两套逻辑。

所以完整的路径改造至少要覆盖三个方向：环境目录、包缓存目录、pip 的下载缓存。前两个归 conda 管，第三个归 pip 管，而 pip 的缓存放在%LOCALAPPDATA%\pip\Cache，默认也在 C 盘，一年半载下来攒个三五 G 很正常。这三个口子堵住，C 盘才算真正松口气。

另外还有一个隐性的大户：Jupyter 的 kernel 配置。你在环境里装了 ipykernel 之后执行注册命令，kernel 的 spec 文件默认写到用户目录的AppData\Roaming\jupyter\kernels下，虽然每个只有几十 KB，但如果你有二十个环境，那就是二十个散落在 C 盘的小文件夹，清理起来特别烦。这部分也能重定向，方法放在第 4 节一起讲。

2.2 路径本身也会挖坑

路径这件事，看着简单，实际上有一堆细节能让 conda 直接罢工。我按踩坑频率从高到低排：

第一是中文和空格。D:\我的软件\Anaconda\envs这种路径，在纯英文环境里工作得好好的，一旦遇到某些编译型包（需要调用系统编译器的那些），大概率报错，而且报错信息完全不指向路径，让你在前面排查半天。我现在的原则是路径里只允许出现字母、数字、下划线和短横线，父目录名一律用conda、envs、pkgs这种纯英文短词。

第二是反斜杠转义。.condarc是 YAML 格式，反斜杠在里面是转义字符，写D:\conda\envs轻则路径变成D:condaenvs，重则 YAML 解析直接失败。最省心的写法是用正斜杠D:/conda/envs，Windows 完全认。如果非要用反斜杠，就得写成双反斜杠D:\\conda\\envs，多敲几下键盘，还容易漏。

第三是盘符和目录必须真实存在。.condarc里写了一个不存在的目录，conda 不会帮你创建，只会判定不可写然后回退。所以正确顺序是：先在资源管理器里把D:\conda\envs和D:\conda\pkgs建出来，再去写配置。

第四是别放在同步盘或网络盘里。有些人图方便把环境放在同步目录下，结果创建环境的时候成千上万个小文件被同步客户端疯狂占用，速度慢到怀疑人生，还偶发文件锁冲突。环境目录属于高频读写的本地数据，老老实实放在本地物理盘上。

第五是文件编码。用记事本编辑.condarc时，默认可能存成带 BOM 的 UTF-8，conda 解析时偶尔会报莫名其妙的 YAML 错误。用 VS Code 或者 Notepad++ 打开，确认编码是 UTF-8 无 BOM，这个习惯能省下不少无意义的排查时间。

2.3 别把"改默认路径"和"搬安装目录"混为一谈

这两个操作在别人的教程里经常被混着说，但风险等级差着数量级。

改默认路径指的是修改envs_dirs和pkgs_dirs，让以后新建的环境落到别的盘。这是纯配置层面的改动，风险极低，随时可以改回来，我不会紧张。

搬安装目录指的是把整个 Anaconda 安装文件夹从 C 盘剪切到 D 盘。这个操作会带来一连串后果：开始菜单快捷方式失效、PATH 环境变量还指着老路径、conda 内部记录的各种绝对路径全部错乱，最直接的表现就是命令行敲conda提示找不到命令，或者能找到但执行任何操作都报错。真要搬，正确做法是卸载后重新安装到目标盘，而不是剪切粘贴。

还有一种中间态，是很多人想干的：保留安装目录不动，只把环境和缓存搬走。这个思路完全正确，也是我推荐的做法——安装本体占的那几个 G 属于一次性开销，不动它风险最小；环境和缓存才是会随使用量无限膨胀的部分，把它们挪走就能解决 90% 的空间焦虑。

3. 三种改法，按场景对号入座

3.1 全局配置法：改 .condarc（首选）

这是我给所有人的第一推荐，因为它一次性、永久生效，且对之后所有conda create都管用。

.condarc的位置在用户主目录下，Windows 上就是C:\Users\你的用户名\.condarc。这个文件默认可能不存在，需要手动创建。最直接的方式是用命令行生成，conda 会自动处理好格式：

conda config --add envs_dirs D:/conda/envs conda config --add pkgs_dirs D:/conda/pkgs

--add的作用是加到列表最前面，这正是我们要的效果——让新路径成为第一顺位。执行完打开.condarc看一眼，内容大致长这样：

envs_dirs: - D:/conda/envs pkgs_dirs: - D:/conda/pkgs

如果你习惯手写，直接创建这个文件、粘进去、保存，效果一样。要注意 YAML 的缩进是两个空格，列表项前面的短横线后面跟一个空格，这些细节错了会导致解析失败。

验证环节千万别省，敲两条命令：

conda config --show envs_dirs conda info

第一条看配置列表里D:/conda/envs是不是排第一，第二条在输出里找envs directories这一段，确认同样的顺序。两个结果对上了，才算真的生效。

提醒：--add和--append是两个不同的命令，前者插入到列表头部，后者追加到尾部。列表里已经存在同一个路径时，--add会自动去重，不会重复添加。

3.2 命令行参数法：-p 指定一切

有时候你只是临时想在某个体积大的项目目录旁边建个环境，让环境和代码待在一起，方便管理，也不想动全局配置，那就用-p/--prefix直接指定完整路径：

conda create -p D:/work/projectA/venv python=3.11 numpy pandas

这个环境不会出现在envs_dirs里，它的名字就是那串路径。激活的时候也得带完整路径：

conda activate D:/work/projectA/venv

用-p建的环境有个特点，conda 会把它记到用户目录下的environments.txt文件里，所以conda env list依然能看到它，列表里显示的是完整路径而不是短名字。

这种方法的优势是粒度细、无副作用，适合临时项目、多版本并存、或者你压根不想让 conda 的全局配置影响自己。缺点是每次激活都要打一长串路径，手滑打错一个字就找不到环境，建议配合终端的历史补全或者写个别名。另外注意一点：-p建的环境不代表它不受 pkgs_dirs 影响，包缓存还是走全局配置，所以第 1.2 节说的同盘原则依然适用。

3.3 环境变量法：给整台机器兜底

第三种是通过系统环境变量CONDA_ENVS_PATH和CONDA_PKGS_DIRS来覆盖。这一招主要用在两个场景：一是多人共用的机器，希望所有用户都按统一规则来；二是 conda 的配置文件出了什么问题，需要快速验证是不是配置本身在捣鬼。

设置方式在 PowerShell 里是：

[Environment]::SetEnvironmentVariable("CONDA_ENVS_PATH", "D:\conda\envs", "User")

在传统的 cmd 里则是：

setx CONDA_ENVS_PATH "D:\conda\envs"

注意setx设置的是持久变量，需要重开一个终端窗口才能看到效果，当前窗口里set的临时变量不会持久。多路径用分号隔开。

我要强调一点：环境变量的优先级高于.condarc。这意味着如果你两边都设了，实际生效的是环境变量，.condarc里的配置会被压住。我见过有人改完配置文件怎么都不生效，排查半天发现是很久以前设过一个CONDA_ENVS_PATH忘掉了。所以排查时第一步就是看环境变量，echo %CONDA_ENVS_PATH%（cmd）或者$env:CONDA_ENVS_PATH（PowerShell），一眼就知道有没有历史遗留。

日常使用我不太推荐这一招，因为它是个"隐形配置"，看不见摸不着，过半年自己都忘了设过，给排查增加成本。它更适合作为兜底或者临时验证手段。

4. 完整实操：从体检到验证

4.1 先做现状体检

正式动手之前，我习惯先跑一遍体检，把现状摸清楚，避免改完之后"好像生效了又好像没有"。

第一步，看配置来源：

conda config --show-sources

这条命令会列出 conda 读到的所有配置文件及其路径，Windows 上通常能看到系统级的C:\ProgramData\conda\.condarc和用户级的C:\Users\你的用户名\.condarc两个。如果两处都有envs_dirs配置，用户级的会覆盖系统级的。看到系统级配置里有内容而你没印象，说明是安装时写进去的，改的时候要连它一起改，别只改用户级。

第二步，看当前生效值：

conda config --show envs_dirs conda config --show pkgs_dirs

第三步，看实际环境分布：

conda env list

列表里会列出所有环境及其路径，一眼就能看出哪些还在 C 盘。顺手把C:\Users\你的用户名\.conda和C:\Users\你的用户名\AppData\Local\pip\Cache这两个目录的大小看一眼，心里对要腾出多少空间有个数。

第四步，检查环境变量：

$env:CONDA_ENVS_PATH $env:CONDA_PKGS_DIRS

输出为空说明没设，设了但不确定是不是历史遗留，就要掂量一下要不要清掉。

这套体检下来，通常五分钟能定位到问题出在哪个环节。我见过太多人一上来就改配置，改完发现没用，才开始找原因，反而绕远路。

4.2 写配置文件并确认生效

体检没问题之后开始改。完整流程我按顺序写一遍，你照着做就行。

**第一步，建目录。**先在资源管理器里手动创建D:\conda\envs和D:\conda\pkgs。别指望 conda 帮你建，它只会判断"可写与否"，不会创建父目录。

**第二步，清掉干扰项。**如果体检时发现有CONDA_ENVS_PATH之类的环境变量，先删掉。PowerShell 里删：

[Environment]::SetEnvironmentVariable("CONDA_ENVS_PATH", $null, "User")

**第三步，写配置。**用命令行最稳：

conda config --add envs_dirs D:/conda/envs conda config --add pkgs_dirs D:/conda/pkgs

如果想要一个更干净的配置，也可以直接手写.condarc：

envs_dirs: - D:/conda/envs pkgs_dirs: - D:/conda/pkgs

手写的话建议把原有内容一起保留，比如channels那些，别覆盖掉。

第四步，验证顺序。

conda config --show envs_dirs

输出里D:/conda/envs必须排在第一个。如果排在后面，说明用的是--append或者列表里有重复项，用conda config --remove envs_dirs 老路径清掉重新来。

**第五步，权限确认。**这一步很多人跳过，但它恰恰是"配置不生效"的头号原因。在资源管理器里右键D:\conda\envs，看属性里的只读是否勾选；如果你用的是公司电脑，还要确认当前账户对这个目录有没有写权限。一个快速验证方法是直接在终端里cd D:/conda/envs然后mkdir test，能建出来就说明可写，建完删掉。

4.3 建环境验证落盘位置

配置改完，必须真建一个环境验证，别拿正式项目试水，建个空的就行：

conda create -n pathtest python=3.10 -y

然后：

conda env list

看pathtest后面跟的路径是不是D:\conda\envs\pathtest。同时去资源管理器里确认一下这个文件夹真的出现在 D 盘上。如果还是跑 C 盘，直接跳到第 6 节看排查表。

顺便验证一下包缓存是否也跟着走了：装个小包，比如conda install -n pathtest requests -y，然后看D:\conda\pkgs下有没有新出现的包目录。这一步确认了，说明硬链接能正常走同盘路径，后续装大包会快很多。

验证完记得清理：

conda env remove -n pathtest

清理的同时也检查一下D:\conda\pkgs的大小变化，正常应该只有几 MB。

4.4 补齐 pip 与 kernel 的路径

conda 管好了，还有两个大户要收拾。

**pip 缓存。**先看当前缓存位置和大小：

pip cache dir pip cache info

改到 D 盘：

pip config set global.cache-dir "D:/pip-cache"

这条命令会写进%APPDATA%\pip\pip.ini，属于用户级配置，对所有环境生效。想验证的话再跑一次pip cache dir，输出变了就对了。顺便提一句，pip 缓存攒久了直接删目录就行，没有依赖关系，删了下次重下而已。定期pip cache purge也能清。

**Jupyter kernel。**在每个环境里装完 ipykernel 之后，注册 kernel 时控制写入位置：

python -m ipykernel install --prefix D:/jupyter-kernels --name myenv --display-name "Python (myenv)"

这样 kernel 的 spec 文件就写到 D 盘了。如果你习惯用--user参数，它会写到用户目录，那还在 C 盘，两者别混用。另外记得装完包之后重新注册一次，否则 Jupyter 里看到的还是旧环境的包列表，这是另一个高频困惑点。

5. 已经建在C盘的环境如何搬家

5.1 clone 法最稳

前面讲的是"以后新建的环境去哪"，但现实往往是：C 盘已经躺了三四个环境，每个都配好了各种依赖，你不可能删了重建。

最稳的办法是--clone克隆。先用conda env list查清老环境的名字，比如叫oldproj，然后在同一个终端里：

conda create -n oldproj_new --clone oldproj

克隆过程会完整复制一份环境，包括所有已安装的包。由于此时envs_dirs已经指向 D 盘，新环境会自动落在D:\conda\envs\oldproj_new。

克隆有几个要注意的点。一是耗时，跨盘克隆走的是文件复制，一个大环境十几分钟很正常，中途别关终端。二是克隆会带上一堆历史垃圾，老环境里那些手滑装错又没卸干净的包、pip install遗留的残留目录，统统会被复制过去，所以克隆完最好跑一次conda list --explicit大致看看包列表有没有异常项。三是克隆不会带上手动改过的配置文件，比如你在环境里改过某些sitecustomize.py，或者有pip装的本地开发包（pip install -e），这些需要手动重新处理。

克隆完验证没问题了，再删老环境：

conda env remove -n oldproj

这里有个小提醒：conda env remove删环境的时候不一定把pkgs里对应的包缓存一起清掉，所以删完跑一次conda clean --all更彻底，能把无引用的缓存包清出去。

5.2 导出 yml 重建

如果你的目标不只是换位置，而是想顺便"净化"一下环境，那导出重建是更好的选择。

conda activate oldproj conda env export --from-history > env.yml

--from-history这个参数很关键，它只导出你显式安装过的包，不导出 conda 自动拉进来的几百个依赖。不带这个参数导出的 yml 会把所有依赖的精确版本号都写进去,换一台机器或者换个平台（比如从 Windows 换到 Linux）经常出现"找不到对应版本"的报错。

即便如此，导出的文件里大概率还会有一行prefix: C:\Users\xxx\.conda\envs\oldproj。这一行必须手动删掉，否则重建的时候 conda 会试图往那个路径装，直接报错。这是新手最常踩的坑之一。

删完之后重建：

conda env create -f env.yml -n newproj

重建的好处是环境干净、体积小、依赖关系清晰；坏处是耗时长，而且如果原来的环境里有pip install装的包（不是通过 conda 装的），--from-history是导不出来的，需要你手动整理成requirements.txt再补一刀。

5.3 直接剪切目录的代价

我必须专门说一段这件事，因为网上确实有教程教人"直接把 envs 文件夹剪切到 D 盘"。

这个操作在极少数情况下能成，但失败的场景非常多，原因在于 conda 环境内部有大量绝对路径引用。Python 解释器启动时会去找sys.prefix，脚本的 shebang 里写死了解释器路径，conda 的元数据文件conda-meta/*.json里记录着每个包的文件清单和原始位置，Scripts目录下那些.bat和.exe启动器全都指向老路径。你把整个文件夹一剪，这些引用全断，环境表面上还在，一激活就是各种ImportError、ModuleNotFoundError，或者执行 pip 的时候提示找不到解释器。

我试过一次，环境能激活，python能进，但pip list报错，装任何包都失败，最后只能删了重来。所以我的态度很明确：能不剪切就别剪切，用 clone 或者 export 重建，多花十几分钟，省下来的排查时间够你喝两杯咖啡。

如果实在要挪，唯一相对安全的路径是：克隆到新位置 → 验证能正常导入常用包 → 删掉老环境。这个流程本质上还是 clone，只是终点明确。

6. 踩坑实录与排查速查

6.1 "配置改了但没用"的五种原因

这个现象太高频了，我单独列一下，按发生概率排序：

第一种，配置写在了错误的位置。.condarc必须放在用户主目录，不是 Anaconda 安装目录。有些人在安装目录下建了一个，改了半天没反应，因为 conda 根本不读那里。用conda config --show-sources一看就知道 conda 到底读了哪些文件。

第二种，环境变量把配置压住了。CONDA_ENVS_PATH优先级高于.condarc，这是最容易忽略的一个。查$env:CONDA_ENVS_PATH有没有值，有就清掉。

第三种，列表顺序不对。用--append加进去的路径排在末尾，前面还有 C 盘路径，conda 当然还是往 C 盘写。用--add或者手动调顺序。

第四种，目标目录不存在或不可写。conda 不会创建目录，也不会提示你目录不存在，只会静默回退。手动建好目录，确认可写。

第五种，改了配置没重开终端。.condarc是每次执行 conda 命令时读取的，理论上改完立刻生效，但环境变量那种方式必须新开终端。另外有些 IDE 内置终端会缓存环境变量，遇到诡异情况先重启 IDE 试试。

还有一种少数情况：安装了两个 conda 发行版（比如一个完整版一个精简版），终端里实际调用的是另一个，改的配置当然不起作用。用where conda查一下实际调用的路径就能确认。

6.2 常见报错对照表

我把这些年遇到的、以及帮别人排查过的典型问题整理成一张表，遇到症状直接对号入座：

这张表我建议存一份，尤其是前两条，能覆盖掉九成以上的求助场景。真遇到表里没有的症状，先用conda info和conda config --show-sources把现状打出来，八成能看到问题所在。

7. 一些实操层面的碎碎念

配置改完之后有件事值得养成习惯：定期看一眼conda clean --dry-run。这条命令会列出可清理的缓存包、无用的 tar 包、索引缓存，加起来往往有几个 G。加-y实际执行就行，它对环境没有任何破坏性，只是把已安装环境不再引用的包缓存删掉。我一般一两个月跑一次，配合 pip 的pip cache purge，C 盘能常年保持一个健康的余量。

另一个我踩过好几次的坑是多版本共存时的命名混乱。当你有了 D 盘的环境目录，又偶尔用-p在项目目录建环境，再加上可能残留的 C 盘老环境，conda env list会变成一个挺长的清单，而且路径型的条目和名字型的条目混在一起，激活的时候经常打错。我的做法是给环境名加前缀，比如proj_开头表示项目专用，test_开头表示临时试水，base之外不放任何没有前缀的环境。另外-p建的环境我一般会在项目根目录放一个activate.txt，里面写好激活命令，复制粘贴比手打靠谱。

还有一个小技巧是关于迁移后重新注册 kernel 的。克隆出来的环境，kernel 注册信息其实还是指向老路径的，虽然大多时候能跑，但一旦清理了老环境就会断。稳妥做法是克隆完之后立刻在新的环境里重跑一次ipykernel install，把那行注册信息刷新一遍。同理，像 VS Code 那种会自动扫描 conda 环境的编辑器，切换环境之后最好重启一下编辑器窗口，让它重新扫描目录，不然环境列表里可能还挂着已经删掉的条目。

最后说一个心态层面的体会。路径这件事，配置本身只有几行，难的是理解它背后的决策链条——哪个配置优先、列表顺序怎么算、哪些目录是共享的、哪些是独立的。把这些搞清楚了，以后遇到任何"环境跑错位置"的问题，五分钟就能定位。反过来，如果只是照抄几行命令，那下次换个路径写法、换台机器，照样得重新搜一遍。我更推荐你把第 1 节那套决策逻辑吃透，剩下的都是在这套逻辑上填空。