Windows 上用 Anaconda 的人，十个里有八个都动过“把 envs 和 pkgs 挪到 D 盘”的念头，也有一大半人挪完之后打开 C 盘一看，空间该少还是少，甚至挪完反而更紧张了。这个现象特别反直觉：明明.condarc里envs_dirs和pkgs_dirs都改了，conda info也显示路径生效了，为什么 C 盘还是被吃掉几十个 G？我前后在好几台机器上折腾过这件事，从最早只会改.condarc的小白阶段，到后来拿着磁盘分析工具一个个目录去翻，才算把 Anaconda 在 Windows 下占 C 盘的完整链路摸清楚。这篇就把这套排查和治理思路完整讲一遍，重点不是“教你改.condarc”这种一搜一大把的内容，而是那些改完之后依然占 C 盘的隐藏位置，以及每个位置该怎么处理、处理时要注意什么。适合已经被 C 盘红条逼疯的中级用户，也适合刚装完 Anaconda 想提前规划的新手。
1. 先搞清楚 Anaconda 到底把东西写到了哪几个地方
很多人对 Anaconda 占空间的认知停留在“环境”和“包缓存”两块，所以只改envs_dirs和pkgs_dirs。但实际上一套完整的 Anaconda 安装，在 Windows 上至少会在五个不同位置留下体积可观的文件，其中只有两个是.condarc能管的。先把这五个位置列清楚，后面所有操作都是围绕它们展开的。
1.1 五个占地大户的分布图
我把一台典型机器上的占用情况整理成下面这张表，数值是量级参考，不同人装的包不一样会有出入，但比例关系基本一致：
| 位置 | 典型路径 | 体积量级 | 是否受.condarc控制 |
|---|---|---|---|
| 基础环境本体 | C:\Users\<用户>\anaconda3或C:\ProgramData\anaconda3 | 3~6 GB | 否 |
| 包缓存 pkgs | 默认在基础环境下的pkgs目录 | 5~20 GB | 是（pkgs_dirs） |
| 虚拟环境 envs | 默认在基础环境下的envs目录 | 每个环境 1~5 GB | 是（envs_dirs） |
| 用户级缓存 | C:\Users\<用户>\.conda、.cache、AppData\Local\conda | 几百 MB 到数 GB | 部分 |
| 安装包与临时文件 | 下载的.exe、AppData\Local\Temp下的解压残留 | 1~3 GB | 否 |
看这张表就能明白问题所在：.condarc只能管中间两行，而基础环境本体、用户级缓存、临时文件这三块它完全管不着。所以“改了 envs 和 pkgs 还是占 C 盘”根本不是配置没生效，而是你改的那两项本来就不是全部。这是理解整件事的第一个关键认知。
1.2 为什么基础环境本体动不了
基础环境（base）是 Anaconda 安装时写死在安装目录里的，它的路径在安装那一刻就固化进了注册表、开始菜单快捷方式、conda可执行文件的启动脚本里。你没法像挪 envs 那样简单地在配置里指一个别的路径就搬走它，因为conda命令本身就跑在这个目录里。想搬 base，本质上等于“卸载重装到别的盘”，这是另一套操作，后面单独讲。
这里有个常见误区要提醒：有人以为把整个anaconda3文件夹剪切到 D 盘就算搬家了，结果conda命令直接失效，因为快捷方式和环境变量还指着 C 盘原路径。文件夹搬家这种做法在 Windows 上对 Anaconda 基本行不通，除非你连带把环境变量、快捷方式、注册表项全部手工改一遍，成本高且容易出错，不推荐。
1.3 用户级缓存为什么容易被忽略
.conda目录里存的是环境列表、配置备份、部分包的元数据；AppData\Local\conda里则有日志、临时解压目录、部分下载缓存。这些东西单个不大，但日积月累能到几个 G，而且它们的位置由环境变量CONDA_ROOT、CONDA_PKGS_DIRS以及系统临时目录共同决定，.condarc里的pkgs_dirs对它们只有部分影响。很多人清完 pkgs 发现 C 盘没怎么变，往往就是这几块在偷偷占着。
2. 改.condarc只是第一步，而且很多人改错了
既然.condarc管不了全部，那是不是就不用改了？当然不是，它管的恰恰是增长最快、最容易失控的两块——envs 和 pkgs。问题在于，很多人改的方式本身就有毛病，导致“看起来改了其实没完全生效”。
2.1.condarc的正确写法和常见错误
标准的写法是在用户目录下建C:\Users\<用户>\.condarc，内容大致如下：
envs_dirs: - D:\conda\envs pkgs_dirs: - D:\conda\pkgs看起来简单，但坑不少。第一个坑是路径里的反斜杠。YAML 里反斜杠是转义字符，直接写D:\conda\envs在某些解析场景下会出问题，稳妥的做法是用正斜杠D:/conda/envs，或者用双反斜杠。我一般统一用正斜杠，跨平台习惯也一致。
第二个坑是目录必须先存在。envs_dirs和pkgs_dirs指向的目录如果不存在，conda 在部分版本里不会自动创建，而是静默回退到默认路径。你以为改成功了，实际新环境还是建在 C 盘。所以改配置之前，先把D:\conda\envs和D:\conda\pkgs手动建好。
第三个坑是多个配置文件打架。conda 的配置是有优先级的：命令行--参数 > 环境变量 > 当前目录的.condarc> 用户目录的.condarc> 系统级配置。如果你在系统级也放过一份.condarc，或者设过CONDA_ENVS_PATH这类环境变量，它们可能覆盖你用户目录的配置。排查时用conda config --show-sources把所有生效的配置源列出来，一眼就能看出谁在捣乱。
2.2 验证配置是否真的生效
改完别急着建环境，先验证。三个命令按顺序跑：
conda config --show-sources conda config --show envs_dirs conda config --show pkgs_dirs第一条列出所有被读取的配置文件及其路径，确认你改的那份在列表里且优先级最高。后两条直接打印当前生效的目录列表，注意它是个列表，第一个是首选路径。如果第一个还是 C 盘路径，说明有更高优先级的配置在覆盖，回去查--show-sources的结果。
还有一个更直接的验证方法：建一个空环境看它落在哪。
conda create -n testpath python=3.10 --dry-run--dry-run只模拟不实际创建，输出里会显示环境将被创建到的完整路径。这一步能立刻暴露配置是否真的生效，比看配置文件靠谱得多。我习惯每次调整路径配置后都跑一遍这个，确认无误再正式建环境。
2.3 已经建在 C 盘的环境怎么迁
配置改好只对新建环境生效，已经存在的环境还躺在 C 盘。这时候有两个选择：删了重建，或者用conda create --clone克隆到新路径再删旧的。克隆的方式适合环境里装了很多包、重建成本高的情况：
conda create -n newname --clone oldname conda remove -n oldname --all注意克隆出来的环境名可以不同，但克隆过程会完整复制包，耗时和占空间都翻倍，磁盘紧张时反而可能中途失败。所以如果环境不算复杂，我更推荐直接conda env export > env.yml导出依赖清单，删掉旧环境后在新路径按清单重建，干净利落，还能顺便清理掉一些历史遗留的无用包。
3. 那些.condarc管不到的角落，才是 C 盘真正的黑洞
到这一步，envs 和 pkgs 都挪走了，旧环境也清了，理论上 C 盘该松口气了。但很多人这时候一看，空间还是没回来多少。原因就在这一节——几个.condarc完全管不到、但体积一点都不小的位置。
3.1 包缓存清理的隐藏残留
conda clean是清理包缓存的正规命令，常用组合是：
conda clean --all它会清掉未使用的包、tar 包、索引缓存、锁文件等。但有个细节：conda clean清的是当前配置下 pkgs_dirs 指向的目录。如果你之前 pkgs 在 C 盘、后来才改到 D 盘，那 C 盘旧 pkgs 目录里的历史缓存，conda clean在新配置下根本不会去碰它，因为那已经不是“当前 pkgs 目录”了。这就是为什么有人跑完conda clean --all发现 C 盘纹丝不动——旧缓存成了孤儿目录。
处理办法是手动去旧路径看一眼。默认旧 pkgs 在C:\Users\<用户>\anaconda3\pkgs或C:\ProgramData\anaconda3\pkgs，确认里面没有正在使用的环境依赖后，整个目录删掉即可。删之前建议先跑一次conda clean --all把能正规清理的先清掉，剩下的手动删更安全。
3.2 临时目录里的解压残骸
Windows 的AppData\Local\Temp是另一个重灾区。conda 安装包时会在这里解压，正常情况下装完会清理，但遇到安装中断、网络波动、权限问题时，解压出来的临时文件会残留下来，而且往往是大批量的.tar.bz2解压产物。这些文件没有统一命名规律，靠肉眼找很费劲。
我的做法是装完大包之后顺手看一眼 Temp 目录，按修改时间排序，把明显是 conda 相关的临时文件夹清掉。更省事的办法是用系统自带的磁盘清理工具，或者第三方磁盘分析工具按目录大小排序，一眼就能定位到异常大的临时目录。注意清理 Temp 时不要删正在运行程序占用的文件，清之前关掉所有 conda 相关窗口。
3.3 用户级.conda与AppData下的 conda 目录
C:\Users\<用户>\.conda里主要是环境和配置的元数据，体积通常不大，但如果你装过很多环境又删过，里面可能残留环境记录。AppData\Local\conda里则有日志和部分缓存，日志文件日积月累也能到几百 MB。
这两个目录不建议整个删除，.conda删了会丢失环境列表信息，AppData\Local\conda删了可能影响 conda 的部分功能。稳妥做法是进去看子目录，日志类的可以直接清，缓存类的可以清，配置和元数据类的保留。这类清理属于“细水长流”，单次收益不大，但定期做能防止慢慢膨胀。
4. 从根上解决：安装阶段就把 base 放到别的盘
前面所有操作都是在“已经装在 C 盘”的前提下做补救。如果你的 C 盘已经非常紧张，或者你正准备重装，那最彻底的办法是在安装阶段就把整个 Anaconda 装到 D 盘，从源头避免 base 本体占 C 盘。这一步能一次性解决基础环境本体那 3~6 GB 的问题，是前面所有技巧都替代不了的。
4.1 安装时的路径选择与注意事项
Anaconda 安装程序默认往C:\Users\<用户>\anaconda3装，安装界面里有一个路径输入框，直接改成D:\anaconda3即可。这里有几个实操要点：
第一，路径不要有空格和中文。虽然现在 Windows 对中文路径支持好了很多，但 conda 生态里不少包在编译、链接阶段对路径敏感，带空格或中文的路径偶尔会触发莫名其妙的错误。用纯英文、无空格的路径最稳。
第二，不要装在需要管理员权限才能写的目录。装在D:\anaconda3这种用户可写的普通目录最省心，避免后续建环境、装包时因为权限问题失败。
第三，安装类型选“Just Me”还是“All Users”。选“Just Me”装到用户目录，权限简单；“All Users”装到ProgramData下，多用户共享但权限配置更复杂。个人机器一律选“Just Me”，配合自定义路径装到 D 盘，是最干净的组合。
4.2 装完之后必须做的收尾配置
装到 D 盘不代表万事大吉，装完立刻做三件事，把后续增长也引导到 D 盘：
- 建好
D:\conda\envs和D:\conda\pkgs两个目录。 - 在
C:\Users\<用户>\.condarc里写入envs_dirs和pkgs_dirs指向这两个目录。 - 跑
conda config --show-sources和conda create -n testpath python=3.10 --dry-run验证。
这样 base 在 D 盘、envs 在 D 盘、pkgs 在 D 盘，C 盘只剩用户级缓存那点小头，基本可以忽略。这套组合是我目前认为在 Windows 上最省心的方案，一次配置，长期不用再操心。
4.3 重装前如何备份现有环境
重装意味着现有环境全没，所以重装前先把环境清单导出来：
conda env list conda env export -n 环境名 > 环境名.yml对每个需要保留的环境都导一份。重装完成后用conda env create -f 环境名.yml逐个恢复。注意导出的 yml 里会带prefix字段记录原路径，恢复时如果路径变了，这个字段可能引起警告，可以手动删掉prefix那一行再恢复，更干净。另外 yml 里记录的是精确版本号，如果某些包在新环境下装不上，可以适当放宽版本约束，这个要按实际情况调。
5. 一套可复用的定期维护清单
配置一次不等于一劳永逸，conda 用久了缓存还是会涨。我给自己定了一套轻量维护习惯，每隔一两个月跑一次，基本能让 C 盘占用长期稳定在低位。这套清单不复杂，关键是养成习惯。
5.1 每月一次的清理动作
按顺序执行下面几条，覆盖了绝大部分可回收空间：
conda clean --all conda env list第一条清包缓存和索引，第二条列出所有环境，人工扫一眼有没有早就不用的环境。有的话conda remove -n 环境名 --all删掉。删环境时注意别删到 base，base 是删不掉的，但误操作其他正在用的环境会带来麻烦，删之前确认环境名。
清理完再去旧 pkgs 路径和 Temp 目录扫一眼，确认没有新的孤儿缓存堆积。这一步花不了几分钟，但能防止缓存悄悄涨回去。
5.2 判断哪些环境可以安全删除
删环境最大的顾虑是“删了以后要用怎么办”。我的判断标准很简单：连续两个月没激活过的环境，基本可以删。真要再用，按之前导出的 yml 重建就行，成本可控。反过来，那些天天激活的环境，哪怕占空间也留着。
还有一个技巧是给环境起有意义的名字，比如按项目或用途命名，而不是env1、env2这种。时间一长，光看名字就能判断这个环境还要不要，省去逐个激活查看的麻烦。这个习惯看似小事，但对长期维护帮助很大。
5.3 长期不用的包和环境的处理策略
有些包装了但项目结束后就再没用过，它们躺在环境里占着空间。处理策略分两种：如果整个环境都不用了，直接删环境；如果只是环境里某几个包不用了，可以conda remove单独卸载，但要注意别误删被其他包依赖的包，conda 会提示依赖关系，看清楚再确认。
对于确实拿不准的，我倾向于保留环境、删掉环境里明显冗余的大包（比如一些体积大的深度学习框架的旧版本），这样既不影响环境可用性，又能回收一部分空间。判断哪些包体积大，可以用conda list配合磁盘分析工具看环境目录下各子目录的大小，心里有个数。
6. 几个容易踩的坑和我的实际处理经验
前面讲的都是“应该怎么做”，这一节讲“实际做的时候会碰到什么”。这些经验大多是我自己踩坑踩出来的，文档里一般不写，但真遇到了很耽误事。
6.1 权限问题导致清理失败
在ProgramData下装的 Anaconda，清理 pkgs 或删环境时经常遇到“拒绝访问”。这是因为那些目录的属主是系统账户，普通用户没有完全控制权。解决办法是用管理员身份打开命令行再执行清理命令，或者提前把目录权限改成当前用户可写。改权限要谨慎，只改 conda 相关目录，别动系统目录。
还有一种情况是文件被占用导致删不掉，通常是某个 Python 进程还在跑。清理前先确认没有 conda 环境处于激活状态，关掉所有相关终端和 IDE，再执行删除。
6.2 路径改了但新环境还是建在 C 盘
这个前面提过，但值得再强调一次，因为它太常见了。除了配置文件优先级问题，还有一个隐蔽原因：环境变量CONDA_ENVS_PATH。有些教程会让你设这个环境变量来改路径，但它和.condarc的envs_dirs是两套机制，同时存在时环境变量优先级更高。如果你之前设过又忘了，.condarc改了也白改。用echo %CONDA_ENVS_PATH%检查一下，有的话清掉，统一用.condarc管理更清晰。
6.3 迁移后环境激活报错的排查思路
用克隆或手动迁移的方式挪环境后，偶尔会遇到激活时报路径相关的错。根因通常是环境里某些包的脚本里硬编码了旧路径。排查思路是：先看报错信息里提到的路径，确认是不是旧路径；如果是，检查该环境下的Scripts目录里有没有写死路径的.bat或配置文件；找到后手动改成新路径，或者干脆重建环境。
这类问题在纯 Python 包里少见，多出现在带编译产物的包或需要写注册表的包上。遇到时不用慌，大部分情况重建环境比修路径更省时间，除非环境特别复杂。
6.4 磁盘分析工具在排查中的实际用法
光靠猜很难定位到底是谁占了空间，我习惯用磁盘分析工具按目录大小排序看。打开工具后直接看 C 盘根目录下各文件夹的大小，重点看Users、ProgramData这两个，再逐层往下钻到 conda 相关目录。这样能直观看到每个位置的体积，比一条条命令查快得多。
用这类工具时注意一点：它扫描的是当前磁盘状态，如果某些文件正被占用，大小可能显示不准。所以最好在没跑 conda 相关程序的时候扫描，结果更可靠。定位到大目录后，再结合前面讲的五个位置逐一对照，基本不会漏。
7. 关于“彻底解决”这件事的一点个人看法
折腾 Anaconda 占 C 盘这件事，我最大的体会是：没有一劳永逸的“彻底解决”，只有持续可控的“定期治理”。网上很多标题写着“彻底解决”，点进去往往只是教你改.condarc，改完当时看着有效，用几个月缓存又涨回来了。真正让 C 盘长期稳定的，是理解清楚那五个占地位置、把能引导到 D 盘的都引导过去、再配合定期清理习惯。
我现在的做法是：base 装在 D 盘，envs 和 pkgs 也都在 D 盘，C 盘只留用户级那点小缓存，每两个月跑一次conda clean --all加人工扫一眼旧路径和 Temp。这套组合下来，C 盘再没因为 conda 红过。如果你现在正被 C 盘空间困扰，建议按本文的顺序从“搞清楚五个位置”开始，一步步排查，而不是一上来就改配置——先看清楚问题在哪，再动手，效率高得多。
