1. 为什么改了 envs 和 pkgs 路径，C 盘还是被吃掉

1.1 一个让很多人抓狂的真实现象

装完 Anaconda3 之后，C 盘空间肉眼可见地往下掉，这事儿几乎每个在 Windows 上用 Python 的人都遇到过。网上一搜，绝大多数教程都会告诉你：改.condarc，把envs_dirs和pkgs_dirs指到 D 盘去，问题就解决了。你照着做了，conda info一看，路径确实变了，心里踏实了。结果过了两周，C 盘又红了，一查，C:\Users\你的用户名\底下不知道什么时候又冒出来好几个 G 的东西。

这个标题说的就是这件事：改了 envs、pkgs 安装路径，C 盘依旧被占用。这不是你操作错了，而是 Anaconda 在 Windows 上的空间占用从来就不止这两个目录。它像一棵树，你只修剪了两根枝丫，地下的根系还在往 C 盘里扎。

我前后在好几台机器上处理过这个问题，从 128G 小硬盘的轻薄本到 512G 的工作站都踩过，最后总结下来，Anaconda 在 Windows 上占 C 盘的地方至少有六七个，envs和pkgs只是最显眼的两个。这篇文章就把这些"隐形大户"一个个揪出来，给出可落地的迁移方案，并且解释清楚每一步为什么要这么做。

1.2 这篇文章适合谁看

如果你符合下面任意一条，这篇内容就是写给你的：

• 装完 Anaconda 发现 C 盘少了好几个 G，想搞清楚钱花哪了；
• 已经改过.condarc的envs_dirs和pkgs_dirs，但 C 盘依然在涨；
• 用的是小容量固态（比如 256G 甚至 128G），C 盘常年告急；
• 不想重装系统、不想重装 Anaconda，希望在不破坏现有环境的前提下把空间挪出来；
• 想一次性把机制搞明白，以后不再反复折腾。

需要说明的是，本文的操作都基于 Windows 平台下 Anaconda3 的常见安装方式，涉及路径迁移的部分会给出完整步骤和验证方法。不同版本（比如 Anaconda3 2021 系列和 2023 系列）在细节上略有差异，我会在关键处标注。所有命令和路径都以通用形式给出，你替换成自己机器上的实际路径即可。

1.3 先建立一个正确的认知：Anaconda 的空间分布

在动手之前，必须先搞清楚 Anaconda 到底把东西放在哪。很多人以为"装在哪就是哪"，其实不然。Anaconda 的安装目录只是"程序本体"，而运行过程中产生的缓存、环境、配置、临时文件，分散在多个位置。

用一个生活化的类比：Anaconda 的安装目录像是你租的办公室，envs是各个项目组的工位，pkgs是公共仓库，但除此之外，还有前台（配置）、快递柜（缓存）、临时会议室（temp）、员工宿舍（用户目录下的隐藏文件夹）。你只把工位和仓库搬走了，前台和快递柜还在原地堆东西。

下面这张表是我在实际排查中整理的"空间占用地图"，建议先对照自己的机器看一眼：

看这张表就明白了：.condarc只管住了中间两行，剩下的全是"法外之地"。这就是为什么你改了路径，C 盘还是被吃。接下来逐个拆解。

2. 逐个击破：那些被忽略的 C 盘占用大户

2.1 安装目录本体：一开始就选错了位置

最根本的问题往往出在安装那一刻。Anaconda 的 Windows 安装器默认往C:\ProgramData\Anaconda3或者C:\Users\用户名\anaconda3装，很多人一路"下一步"就过去了。这个目录本身就有 3~6 GB，而且它是"程序本体"，.condarc完全管不到它。

如果你还没装，或者愿意重装，最省事的做法就是安装时直接选 D 盘，比如D:\Anaconda3。注意路径里不要有空格、不要有中文，这是老生常谈但真的有人踩。空格会导致某些脚本调用失败，中文路径在某些包的编译环节会出乱码。

如果不想重装，也有办法迁移，但比想象中麻烦，因为注册表、开始菜单快捷方式、环境变量都指向旧路径。我的建议是：如果安装目录占用在可接受范围（比如 5 GB 以内），优先保留不动，把精力放在后面几个更容易迁移的目录上。迁移安装目录的收益/风险比并不高，除非你的 C 盘真的到了极限。

这里有个细节值得说：有些人把 Anaconda 装在 C 盘，但把envs和pkgs指到了 D 盘，结果发现 D 盘的环境跑起来特别慢。原因不一定是路径问题，而是跨盘符的符号链接和文件锁在 Windows 上效率较低，尤其是机械硬盘。所以如果你的 D 盘是机械盘、C 盘是固态，把环境放 D 盘反而拖慢启动。这一点在选路径时要想清楚，别为了省空间牺牲体验。

2.2.conda目录：配置和环境的"影子副本"

C:\Users\用户名\.conda这个目录很多人没注意过。它里面通常有environments.txt（记录所有环境的路径）、pkgs（某些情况下的缓存）、以及各种配置文件。体积一般不大，但如果你频繁创建删除环境，environments.txt会越来越长，偶尔还会残留失效条目。

更关键的是，某些版本的 conda 会在这里放一份"环境元数据缓存"。当你用conda env list时，它读的就是这里。如果这个文件损坏或路径错乱，会出现"环境明明在 D 盘，conda 却找不到"的诡异现象。

处理方式很简单：这个目录不建议整个删掉（会丢配置），但可以定期清理里面的pkgs子目录和失效条目。真正要迁移的是它的"兄弟"——AppData\Local\conda，下面会讲。

2.3 AppData 下的三座大山：conda、pip、Temp

C:\Users\用户名\AppData\Local这个隐藏目录是 Windows 上 C 盘占用的重灾区，Anaconda 相关的主要有三块：

第一块是AppData\Local\conda\conda。这里面存的是 conda 的索引缓存、repodata 缓存。每次conda install或conda search，它都会下载并缓存包索引，这些 JSON 文件单个不大，但累积起来几百 MB 很常见。它不受.condarc的pkgs_dirs控制。

第二块是AppData\Local\pip\Cache。只要你用过pip install，这里就会堆 wheel 缓存。一个中等规模的项目依赖装下来，缓存轻松上 GB。pip 的缓存路径由PIP_CACHE_DIR环境变量控制，默认就在 C 盘。

第三块是AppData\Local\Temp。conda 在解压包、编译、安装过程中会往系统临时目录写大量中间文件。正常情况下装完会清理，但异常中断（比如你 Ctrl+C 了）就会留下垃圾。我见过一台机器 Temp 目录里躺着 8 GB 的 conda 临时文件。

这三块加起来，轻松吃掉好几个 G，而且它们完全不受.condarc影响，这就是"改了路径还占 C 盘"的头号元凶。

2.4 Jupyter 与 IPython：小但烦人的常驻户

C:\Users\用户名\.jupyter和.ipython这两个目录，体积通常不大（几十到几百 MB），但它们是"只增不减"型。Jupyter 的运行时配置、内核规格、检查点，IPython 的历史记录、profile 数据，都堆在这里。如果你经常用 Notebook，.ipython\profile_default\history.sqlite能长到几百 MB。

它们不影响大局，但在清理 C 盘时属于"顺手就能收"的部分。真正需要关注的是它们和虚拟环境的联动——如果你把环境迁到 D 盘，但 Jupyter 内核配置还指向 C 盘旧路径，就会出现"内核启动失败"的问题，这个后面排查章节会细说。

2.5 一个容易被忽视的点：硬链接与"看起来没占"

这里要讲一个稍微反直觉的机制。conda 在安装包时，默认使用硬链接（hard link）把pkgs里的文件链接到envs里的环境目录。也就是说，同一个包文件在磁盘上只存一份，pkgs和envs里看到的是同一个物理文件的两个"入口"。

这个机制的好处是省空间，但坏处是：当你用资源管理器看文件夹大小时，会重复计算。pkgs显示 5 GB，envs显示 5 GB，你以为占了 10 GB，实际可能只有 5 GB。反过来，如果你把pkgs和envs放在不同的盘符，硬链接就失效了，conda 会退化成复制文件，空间反而翻倍。

注意：这就是为什么官方建议pkgs_dirs和envs_dirs尽量放在同一个盘符下。跨盘迁移看似省了 C 盘，实际可能让 D 盘占用暴涨，而且安装速度变慢。这一点在规划路径时务必考虑。

理解了硬链接，你就能明白：单纯看文件夹大小判断占用是不准的，得用专门的工具（比如 WizTree、SpaceSniffer 这类磁盘分析工具）看"实际物理占用"。这也是排查 C 盘问题的第一步。

3. 完整迁移方案：从规划到落地

3.1 迁移前的规划：先算账，再动手

动手之前先做三件事，能避免 80% 的返工。

第一，用磁盘分析工具扫一遍 C 盘。推荐 WizTree（读取 NTFS 的 MFT，速度快）或 SpaceSniffer（可视化方块，直观）。重点看C:\Users\用户名和C:\ProgramData两个目录，把 Anaconda 相关的占用列出来，心里有个数。这一步的目的是确认"到底是谁在占"，而不是凭感觉。

第二，确定目标盘符和目录结构。我的习惯是在 D 盘建一个统一目录，比如D:\DevTools\Anaconda，下面分envs、pkgs、cache三个子目录。统一管理的好处是以后清理、备份、迁移都只盯一个地方。目录名同样避免空格和中文。

第三，确认目标盘剩余空间。迁移不是"移动"，很多时候是"复制后删除"，过程中会短暂占用双份空间。目标盘至少要有源目录 1.5 倍的余量。如果 D 盘也快满了，那就得先清理再迁移，别硬来。

规划阶段还要想清楚一件事：哪些迁、哪些不迁。我的建议是：

• 必迁：pkgs、envs、pip 缓存、conda 索引缓存；
• 建议迁：Temp 中的 conda 临时文件（通过改环境变量）；
• 谨慎迁：安装目录本体（风险高收益低）；
• 不用迁：.jupyter、.ipython（体积小，迁了反而容易出内核问题）。

3.2 迁移 pkgs 和 envs：.condarc的正确写法

虽然标题说"改了依旧占用"，但这一步仍然是基础，只是要写对。.condarc文件的位置在C:\Users\用户名\.condarc，如果没有就自己建一个。内容如下：

envs_dirs: - D:\DevTools\Anaconda\envs pkgs_dirs: - D:\DevTools\Anaconda\pkgs

几个容易写错的地方：

• 缩进用空格，不用 Tab。YAML 对缩进敏感，Tab 会直接报解析错误。
• 路径用正斜杠/或双反斜杠\\，单反斜杠会被当转义符。上面用正斜杠最省心。
• 列表格式的短横线后面要有一个空格，- D:\...而不是-D:\...。
• 不要只写一个路径就以为完事，改完必须验证。

验证命令：

conda info

看输出里的envs directories和package cache两行，确认第一个路径是你设置的 D 盘路径。注意是"第一个"，因为 conda 会保留默认路径作为后备，列表顺序决定优先级。

改完之后，已有的环境不会自动搬过去。你需要手动迁移：先把旧envs下的环境文件夹整个剪切到新位置，然后conda env list看是否还能识别。如果识别不到，说明environments.txt里还记着旧路径，需要手动编辑或重建。

提示：迁移已有环境时，最稳妥的做法是"导出再重建"，而不是直接剪切。用conda env export > env.yaml导出依赖，在新位置conda env create -f env.yaml重建。直接剪切虽然快，但环境里有些包的绝对路径写死在配置文件里，换位置后可能出问题。重建虽然慢，但干净可靠。

3.3 迁移 pip 缓存：改环境变量最干净

pip 缓存不受.condarc管，得单独处理。有两种方式：

方式一：临时改（只对当前命令行窗口生效）

set PIP_CACHE_DIR=D:\DevTools\Anaconda\cache\pip

方式二：永久改（推荐）

在"系统属性 → 高级 → 环境变量"里，新建用户变量PIP_CACHE_DIR，值设为D:\DevTools\Anaconda\cache\pip。这样以后所有 pip 操作都会把缓存写到 D 盘。

改完之后，旧的C:\Users\用户名\AppData\Local\pip\Cache可以直接删掉，释放空间。删之前确认没有正在运行的 pip 进程。

这里解释一下为什么用环境变量而不是配置文件：pip 的配置文件（pip.ini）虽然也能设cache-dir，但它的优先级低于环境变量，而且不同 Python 环境可能读不同的配置文件，容易混乱。环境变量是全局的、优先级高的，最不容易出错。

3.4 迁移 conda 索引缓存：CONDA_PKGS_DIRS之外的手段

AppData\Local\conda这个目录比较顽固，它不完全受.condarc控制。可以尝试设置环境变量CONDA_PKGS_DIRS，但更彻底的做法是定期清理而不是迁移，因为它的内容都是可再生的缓存，删了下次会自动重建。

清理命令（在 Anaconda Prompt 里执行）：

conda clean --all

这个命令会清理索引缓存、未使用的包、tarball 压缩包、临时文件。执行前它会列出要删的内容和体积，确认后再删。我一般一个月跑一次，能稳定回收 1~3 GB。

如果想把AppData\Local\conda整个挪走，可以创建一个目录符号链接（需要管理员权限）：

mklink /D "C:\Users\用户名\AppData\Local\conda" "D:\DevTools\Anaconda\cache\conda"

但符号链接在 Windows 上有坑：某些程序不认链接，会报"路径不存在"。所以这个方案我只在确认没有兼容问题的情况下用，普通用户建议还是靠conda clean定期清理。

3.5 处理 Temp 目录：改TEMP变量要谨慎

conda 安装时的临时文件写在系统TEMP目录。理论上可以把TEMP和TMP环境变量指到 D 盘，但我不建议全局改，因为很多软件依赖系统 Temp 的默认位置，改了可能引发各种奇怪问题（比如某些安装器找不到临时目录）。

更稳妥的做法是：只在需要跑大型 conda 安装时，临时改当前窗口的 TEMP：

set TEMP=D:\DevTools\Anaconda\cache\temp set TMP=D:\DevTools\Anaconda\cache\temp conda install 你的包

这样临时文件写到 D 盘，装完关掉窗口就恢复默认，不影响其他软件。这个技巧在处理超大包（比如 PyTorch 全家桶）时特别有用，能避免 C 盘在安装过程中被瞬间撑爆。

3.6 迁移后的验证清单

迁移不是改完就完事，必须逐项验证。我整理了一份检查清单，照着过一遍：

全部通过，才算迁移成功。任何一项不通过，回到对应章节排查。

4. 实操中踩过的坑与排查实录

4.1 环境迁移后conda activate报错

这是最常见的后遗症。现象是：环境明明在 D 盘，conda env list也能看到，但conda activate就是报"Could not find conda environment"。

原因通常是C:\Users\用户名\.conda\environments.txt里还记着旧路径。这个文件是纯文本，每行一个环境路径。用记事本打开，把旧路径改成新路径，或者直接删掉失效行，保存后重开命令行即可。

还有一种情况是环境目录里的conda-meta文件夹损坏。这时候别硬修，直接用conda env export导出依赖重建，比修快得多。

4.2 硬链接失效导致 D 盘暴涨

前面提过硬链接的机制。如果你把pkgs放 D 盘、envs放 E 盘，或者一个在 C 盘一个在 D 盘，硬链接就失效了，conda 会复制文件。结果是：装一个 2 GB 的包，pkgs占 2 GB，envs又占 2 GB，总占用翻倍。

排查方法：看conda info里pkgs_dirs和envs_dirs是否在同一个盘符。如果不是，尽量调整到同一盘符。如果实在要分开，接受空间翻倍的代价，或者用conda install --no-deps之类的方式减少重复（不推荐，容易缺依赖）。

4.3conda clean之后环境反而坏了

极少数情况下，conda clean --all会删掉某些环境正在使用的包缓存，导致环境里的硬链接指向空文件。现象是环境能激活，但 import 某个包时报"文件不存在"。

这是因为硬链接的"源"被删了。预防办法：清理前先确认没有环境依赖那些缓存。更保险的做法是只清理--tarballs（压缩包）和--index-cache（索引），不动--packages：

conda clean --tarballs --index-cache

这样只删可再生的压缩包和索引，不碰已安装包的缓存，安全得多。

4.4 迁移后 Jupyter 内核启动失败

把环境迁到 D 盘后，Jupyter Notebook 里选内核可能报"Kernel died"或"找不到内核"。原因是 Jupyter 的内核规格文件（kernel.json）里写死了 Python 解释器的绝对路径，环境一搬，路径就失效了。

解决办法：重新注册内核。在目标环境激活后执行：

python -m ipykernel install --user --name 环境名 --display-name "显示名"

这会用当前环境的真实路径重新生成 kernel.json。旧的失效内核可以用jupyter kernelspec list查看，再用jupyter kernelspec remove 旧内核名删掉。

4.5 常见问题速查表

4.6 几条压箱底的经验

经验一：别追求"一次迁完"，分批来。先迁pkgs和envs，观察一周没问题，再处理 pip 缓存和 Temp。一次性全改，出问题很难定位是哪个环节的锅。

经验二：迁移前做个环境清单备份。执行conda env list > envs_backup.txt，把当前所有环境路径记下来。万一迁移出问题，至少知道原来有哪些环境，不至于抓瞎。

经验三：小硬盘用户考虑用 Miniforge 替代。如果你的 C 盘实在紧张，Miniforge（conda 的轻量发行版，默认用 conda-forge 源）安装体积比完整 Anaconda 小很多，而且没有预装一大堆用不上的科学计算包。这不是必须的，但对 128G 设备很友好。

经验四：定期体检比事后抢救重要。我现在的习惯是每月跑一次conda clean --tarballs --index-cache，每季度用 WizTree 扫一次 C 盘。花十分钟，省得某天突然发现 C 盘红了手忙脚乱。

经验五：路径规划要留余地。别把 D 盘塞得满满当当，envs目录会随着项目增加不断膨胀。我一般给 Anaconda 相关目录预留至少 30 GB，实际用下来比较从容。

5. 关于"彻底解决"的一点个人看法

折腾了这么多台机器，我越来越觉得"彻底解决 Anaconda 占 C 盘"这个说法本身要打个折扣。Windows 上的软件生态就是这样，程序本体、用户配置、系统缓存天然分散在多个位置，没有任何一个配置文件能一劳永逸地管住所有。所谓"彻底"，本质是把可控的部分管好，把不可控的部分定期清理。

.condarc管住envs和pkgs，环境变量管住 pip 缓存，conda clean管住索引和临时文件，磁盘分析工具负责定期体检。这套组合拳打下来，C 盘的 Anaconda 占用能压到一个很舒服的水平，剩下的那点安装目录本体，就当是"房租"，认了。

最后分享一个我自己的小习惯：每次新建环境前，先想清楚这个环境大概要装多少东西，装完顺手conda clean --tarballs。养成这个肌肉记忆之后，C 盘再也没红过。比起事后到处找"哪个文件夹又大了"，这种前置的小动作省心太多。