C盘爆满？从Codex缓存分析到开发工具链迁移的全流程

开头

如果你最近打开电脑，看到 C 盘又红了，很可能不是因为你“不会清理”，而是因为开发工具和缓存文件在替你默默地“保存世界”。尤其是新上手 Codex 这类 AI 编程工具的人，往往会有一种错觉：装完就能跑，跑完就没事。但现实是，Codex 的模型缓存、Node.js 依赖、配置文件、日志临时文件，都可能被默认写到 C 盘，而且几乎没有多少人注意到这件事。

这篇文章要讲的，不只是“C 盘满了怎么办”，而是把 Codex 的安装、配置、使用和 C 盘清理结合起来，告诉你一条完整路线：先用 Codex 跑通一个真实任务，再顺藤摸瓜找出 C 盘空间被占用的真正原因，最后把这些年的“存储欠账”一次清理掉。我从这个过程中腾出了 300 多 GB，也找到了很多以前根本不会去翻的盘符角落。如果你愿意照着做，至少能解决 80% 的 C 盘空间焦虑。

我不打算给你罗列一堆清理工具，也不会让你盲目删文件。我更想做的是：先把 Codex 的使用流程走通，再让你理解 C 盘的结构和缓存机制，最后用一套工程化的方式把空间找回来。整个过程不需要第三方流氓软件，也不需要重装系统。

1. 这篇文章真正要解决的问题

先说一个很多人都会遇到的场景：你下载了 Codex 安装包，装好之后可能只看到命令行里的一句“Welcome”，然后就开始写 prompt、生成代码。但你的 C 盘在安装过程中可能经历了以下几个变化：

• 安装包和默认缓存路径全部落在 C:\Users\<用户名>\AppData 下。
• Codex 内部可能基于 Node.js，npm 全局包默认也写在 C:\Users\<用户名>\AppData\Roaming\npm。
• 各种日志、认证凭证、临时下载和模型相关文件会继续占用用户目录。
• 如果你还开了其他 AI 工具、Python 环境、Docker 镜像缓存，C 盘会更快被塞满。

这台电脑对我而言不只是写代码的机器，还是剪视频、开虚拟机、跑本地模型的日常主力机。所以当 C 盘可用空间从两位数掉到个位数，我意识到问题不在“某个文件”，而是很多软件都把“临时数据”默认丢到了系统盘。Codex 只是压垮情节的最后一根稻草，但它也给了我一个梳理全盘的机会。

这篇文章适合以下读者：

• 刚接触 Codex，想把它用到实际项目里的人。
• 已经装了 Codex，但发现 C 盘空间越来越不够用的人。
• 不想用各种“清理大师”，希望理解原理后手工清理的人。
• 想学习如何把开发工具链迁移到 D 盘或其他数据盘的人。

你从这篇文章里至少能得到四样东西：

1. 一套 Codex 的安装、配置和最小任务示例。
2. C 盘空间占用的排查方法。
3. 可复制的清理命令和路径迁移策略。
4. 以后避免 C 盘再次爆满的工程习惯。

2. Codex 是什么？为什么一装就占 C 盘

2.1 Codex 的核心定位

Codex 是 OpenAI 推出的编程智能体工具，简单说，它不只像传统代码补全工具那样帮你“补全下一行”，而是能理解任务目标，在终端里执行命令、读写文件、运行测试甚至调试代码。

放在开发场景里，它解决的核心痛点是：从“我要自己查资料、写代码、跑命令、看报错”，变成“我用自然语言描述一个需求，Codex 去规划步骤并执行”。这和传统 AI 补全工具最大的区别，是它的权限边界和工作方式：它更像一个住在命令行里的实习生，而不是一个只会弹提示框的输入法。

2.2 为什么默认配置会占 C 盘

Codex 的命令行工具在 Windows 上通常沿着用户目录存放配置和缓存，关键路径例如：

• C:\Users\<用户名>\.codex
• C:\Users\<用户名>\AppData\Local 或 AppData\Roaming
• npm 全局目录：C:\Users\<用户名>\AppData\Roaming\npm
• 临时文件目录：C:\Users\<用户名>\AppData\Local\Temp

你可能会问：这能占多大空间？单独看 Codex 本身可能不多，但问题是 Codex 依赖的 Node.js 生态、npm 缓存、Python 环境、编译器缓存这些“配套设施”，很容易在不知不觉中积累到几十 GB。如果模型支持本地缓存运行，那占用会更大。

还有一个隐藏问题：当你把 Codex 安装到 Windows 桌面版或 CLI，某些版本会默认在用户目录下创建大量日志和 session 记录。你平时根本不会去看这些目录，但文件就在那里，而且只增不减。

2.3 新手最容易误解的地方

我见过不少朋友以为“C 盘清理就是删 C:\Windows\Temp”。这没有错，但远远不够。真正占空间的，是用户目录下的 AppData、缓存、Docker 镜像、npm 缓存、pip 缓存、WSL 虚拟磁盘、休眠文件、系统还原点。

所以清理 C 盘的正确顺序应该是：

1. 先分析磁盘占用。
2. 找出占用最大的目录。
3. 区分哪些可以删、哪些可以迁移、哪些必须保留。
4. 再执行清理或迁移。

Codex 的价值恰恰在于：它可以通过自动化命令帮你完成一部分重复分析，比如列出大文件、计算目录大小、清理临时缓存。但前提是你自己也要知道哪些文件是必须保留的。

3. 环境准备与前置条件

在正式使用 Codex 之前，建议先准备好环境。这里以 Windows 11 为例，macOS 或 Linux 思路类似。

3.1 基本环境

3.2 安装 Codex CLI

如果你习惯用命令行，Codex CLI 是更轻量的方式。安装前先确认 Node.js 和 npm 版本：

bash复制node -v
npm -v

如果输出正常，再执行安装：

bash复制npm install -g @openai/codex

安装后检查版本：

bash复制codex --version

这里我提醒一句：如果 npm 全局目录默认写在 C 盘用户目录下，后续会占用 C 盘空间。你可以在 .npmrc 中修改全局安装路径，也可以先不管，等文章第 8 节再统一迁移。

3.3 安装 Codex 桌面版

如果你更习惯图形界面，可以到官方渠道下载桌面版安装包。根据搜索材料来看，Windows 桌面版在安装时同样会默认写入用户目录。安装完成后，通常需要登录账号并授权。

启动后你会看到一个类似聊天界面的工作区，可以指定文件夹作为 Codex 的工作目录。

3.4 登录与模型选择

Codex 通常需要 OpenAI 账号鉴权。命令行下可以执行：

bash复制codex login

它会打开浏览器完成登录，然后把凭证写到用户目录下。如果你所在网络环境无法直接访问对应服务，可能需要配置代理或修改环境变量；这不是本文重点，但你要知道 Codex 的网络请求需要能到达官方 API 端点。

模型选择方面，Codex 可能支持多个模型，例如 gpt-5.6-sol 这类模型名在某些 API 配置中会被限制。搜索材料里有一条错误信息：the 'gpt-5.6-sol' model is not supported when using codex with a ...，这意味着你在配置自定义模型时需要确认模型名称是否被当前 Codex 版本支持。不要盲写模型名。

3.5 最小工作目录

建议在 D 盘或其他数据盘建一个工作目录，例如：

bash复制mkdir D:\codex-projects
cd D:\codex-projects

这样至少能保证 Codex 在生成项目文件时不会默认放到 C 盘。很多空间浪费，本质上是项目目录和缓存目录都堆在系统盘，而不是真的不能迁移。

4. 核心流程拆解：从安装到跑通一个任务

下面我用一个最小示例来讲清 Codex 的完整使用流程。目标很简单：让 Codex 在当前目录下创建一个 Python 脚本，脚本实现“读取一个文本文件，统计单词数量，并输出结果”。

4.1 创建项目目录

推荐在数据盘建立项目目录，比如：

powershell复制D:
mkdir codex-demo
cd codex-demo

4.2 准备一个输入文件

手动创建一个 input.txt：

text复制hello world this is a codex demo
codex helps developers clean disk space

保存后放在当前目录。

4.3 启动 Codex 会话

bash复制codex go

或者在桌面版中选中当前目录作为工作目录。

4.4 写一条准确的任务描述

你可以输入：

text复制请在这个目录下创建一个 Python 脚本，脚本名 word_count.py。它要读取同目录下的 input.txt，统计所有单词的出现次数，按从高到低排序，并输出结果。运行环境是 Windows，使用 UTF-8 编码。

这里为什么强调“准确”？因为 Codex 虽然是智能体，但它仍然依赖你给出的约束。如果不指定脚本名、编码方式、运行环境，它可能生成 Linux 风格的路径写法，或使用非 UTF-8 编解码，导致你运行时报错。

4.5 查看 Codex 执行计划并批准

Codex 通常会展示它将执行的步骤，例如：创建文件、写代码、运行命令。如果你看到它要删除文件或覆盖文件，要特别小心。最小示例里，我们只需要允许它创建文件和运行脚本。

4.6 验证生成文件

如果一切顺利，目录下会多出 word_count.py。打开看一眼，代码可能类似：

python复制# 文件路径：D:\codex-demo\word_count.py
from collections import Counter
import sys


def main():
    input_file = "input.txt"
    try:
        with open(input_file, "r", encoding="utf-8") as f:
            text = f.read()
    except FileNotFoundError:
        print(f"文件不存在: {input_file}")
        sys.exit(1)

    words = text.split()
    counter = Counter(words)
    for word, count in counter.most_common():
        print(f"{word}: {count}")


if __name__ == "__main__":
    main()

这段代码逻辑很简单，但它说明了 Codex 的基本工作方式：它根据自然语言描述生成完整代码，然后我们再去运行验证。

4.7 运行脚本

bash复制python word_count.py

预期输出类似：

text复制hello: 1
world: 1
this: 1
is: 1
a: 1
codex: 2
demo: 1
helps: 1
developers: 1
clean: 1
disk: 1
space: 1

如果输出正确，说明最小流程已经跑通了。

5. 用 Codex 写一个 C 盘清理分析脚本

上面的示例太小，还不足以体现 Codex 的实际价值。现在我们来点更贴合主题的：让 Codex 生成一个 Python 脚本，扫描 C 盘下用户目录的常见缓存位置，统计每个目录占用的空间，并输出前十名。

5.1 为什么要写这个脚本

手动清理 C 盘时，最耗时间的一步是“分析”。Windows 自带的存储设置能看到大概分类，但看不到细粒度的大目录。用脚本扫描，能快速定位占用大户。

5.2 先看一条可能的 Codex prompt

text复制请写一个 Python 脚本 disk_scan.py，功能如下：
1. 扫描指定根目录下的所有一级子目录。
2. 计算每个子目录的总大小，包括递归内部文件。
3. 按大小从大到小排序。
4. 只打印前 10 个目录，输出格式为“大小(GB) 路径”。
5. 如果目录没有权限访问，跳过并记录到日志中。
6. 使用 Windows 路径风格，脚本要兼容 Python 3.10+。

这里我特意加了“跳过无权限目录”和“记录日志”，因为真实扫描 C 盘时，很多系统目录无法直接读取，如果不处理会直接崩溃。

5.3 Codex 可能生成的脚本

Codex 生成的具体代码可能每次都有差异，但核心思路如下：

python复制# 文件路径：D:\codex-demo\disk_scan.py
import os
import sys
import logging
from collections import defaultdict

logging.basicConfig(
    filename="scan_errors.log",
    level=logging.WARNING,
    format="%(asctime)s %(levelname)s %(message)s",
    encoding="utf-8",
)


def get_dir_size(path):
    total = 0
    try:
        for entry in os.scandir(path):
            try:
                if entry.is_file(follow_symlinks=False):
                    total += entry.stat().st_size
                elif entry.is_dir(follow_symlinks=False):
                    total += get_dir_size(entry.path)
            except (PermissionError, FileNotFoundError) as e:
                logging.warning("跳过 %s: %s", entry.path, e)
    except (PermissionError, FileNotFoundError) as e:
        logging.warning("跳过 %s: %s", path, e)
    return total


def main():
    if len(sys.argv) < 2:
        print("用法: python disk_scan.py <根目录>")
        sys.exit(1)

    root = sys.argv[1]
    if not os.path.isdir(root):
        print("路径不存在或不是目录: ", root)
        sys.exit(1)

    sizes = {}
    for name in os.listdir(root):
        full_path = os.path.join(root, name)
        if os.path.isdir(full_path) and not os.path.islink(full_path):
            print(f"正在扫描: {full_path}", file=sys.stderr)
            sizes[full_path] = get_dir_size(full_path)

    print("大小(GB)\t路径")
    for path, size in sorted(sizes.items(), key=lambda x: x[1], reverse=True)[:10]:
        print(f"{size / (1024 ** 3):.2f}\t{path}")


if __name__ == "__main__":
    main()

5.4 运行脚本扫描用户目录

如果你担心扫描整个 C 盘太慢，可以先只扫描当前用户目录：

bash复制python disk_scan.py "C:\Users\<你的用户名>"

这会输出用户目录下各子目录的大小。从我实际遇到的情况看，AppData 经常占据最大比例，所以要进一步深入扫描它：

bash复制python disk_scan.py "C:\Users\<你的用户名>\AppData\Local"
python disk_scan.py "C:\Users\<你的用户名>\AppData\Roaming"
python disk_scan.py "C:\Users\<你的用户名>\.codex"

5.5 如何判断清理目标

脚本输出的只是“哪个目录大”，不代表“哪个目录能删”。你需要再确认目录里的内容。常见可清理或可迁移的对象包括：

6. 运行结果与效果验证

很多人清理完 C 盘后，只会看一眼“可用空间变大了”，但没有验证清理是否误伤。更稳妥的做法是三步验证。

6.1 验证磁盘空间

在 PowerShell 中执行：

powershell复制Get-PSDrive C

或者直接在资源管理器中查看 C 盘属性。清理前后的可用空间对比是最直观的结果。

6.2 验证 Codex 是否仍然正常

清理完缓存后，必须确认 Codex 还能正常登录和执行任务：

bash复制codex login
codex --version

如果无法登录，可能是在清理时误删了 ~/.codex 下的授权凭证。建议不要整目录删除，而是只删除 .codex 下的 logs 等子目录。

6.3 验证 npm 和 Python 是否正常

如果你执行了 npm cache clean --force，需要确认 npm 还能正常安装包：

bash复制npm install -g @openai/codex

如果你清理了 pip 缓存，不影响已有包，但要确认新安装包能正常下载：

bash复制pip install requests

如果这些命令都正常，基本可以说明清理没有破坏开发工具链。

6.4 验证系统功能

重启电脑，打开几个常用软件，确认系统没有异常。特别是如果只清理了临时目录和缓存，一般不会出问题；但如果清理了 System32 或 WinSxS 下的文件，系统就可能无法启动。所以我在后文会反复强调：不要碰系统核心目录。

7. Codex 常见报错与 C 盘清理排查

我整理了一些和 Codex、C 盘清理相关的真实问题和排查思路，不保证覆盖所有场景，但至少能帮你少走弯路。

7.1 Codex 安装或登录失败

7.2 模型不支持

搜索材料中有这样一条错误信息：

text复制the 'gpt-5.6-sol' model is not supported when using codex with a ...

这条提示说明你配置的模型名在当前 Codex 版本或当前 API 场景下不可用。解决办法是打开 Codex 配置文件，把模型名改成官方支持的值。不要盲目相信网上教程里的“新模型名称”，尤其当配置文件里出现未识别设置时，Codex 本身也会提示：

text复制codex is ignoring 1 unrecognized configuration setting. check for typos or ...

遇到忽略配置提示，要优先检查配置文件是否有拼写错误。最稳妥的方式是只保留官方文档中提到的配置项。

7.3 C 盘清理时的权限问题

7.4 C 盘空间清理命令速查

下面这些命令仅针对用户缓存和临时文件，不涉及系统核心组件。执行前请关闭正在运行的开发工具。

powershell复制# 清理 Windows 临时目录中的文件（跳过正在使用的）
del /q /f /s "%TEMP%\*"

# 清空用户 Temp
Remove-Item -Path "$env:TEMP\*" -Recurse -Force -ErrorAction SilentlyContinue

# 清理 npm 缓存
npm cache clean --force

# 清理 pip 缓存
pip cache purge

# 清理 Docker 未使用的数据
docker system prune -f

完整的 docker system prune -a 更激进，会删除所有未被容器使用的镜像和网络缓存，执行前确认没有需要保留的本地镜像。

7.5 恢复分区在 C 盘后面怎么办

搜索热词里有“恢复分区在c盘后面怎么办”。这是 Windows 磁盘管理里常见的尴尬情况：C 盘空间不足，想扩容，但恢复分区挡在 C 盘后面，导致“扩展卷”按钮不可用。

我不建议普通用户直接删除恢复分区。更安全的思路是：

• 购买或准备一块移动硬盘，备份重要数据。
• 使用分区管理工具（如 DiskGenius）或系统自带磁盘管理，在确保备份的前提下调整分区位置。
• 优先尝试清理 C 盘内部垃圾，而不是盲目扩容。

对一个开发者来说，与其研究无损扩容 C 盘，不如先通过迁移缓存目录释放空间。扩容是最后的手段，而不是第一选择。

8. 完整实践：把开发工具链迁移到 D 盘

现在到了这篇文章最有工程价值的部分：把开发工具链中容易写入 C 盘的缓存和依赖目录，迁移到 D 盘或其他数据盘。

8.1 迁移 npm 全局目录

在 PowerShell 中执行：

powershell复制D:
mkdir D:\dev\npm-global
npm config set prefix "D:\dev\npm-global"

然后把 D:\dev\npm-global 加入系统 PATH，并移除旧的 C:\Users\<用户名>\AppData\Roaming\npm。

注意：迁移后，之前全局安装的命令可能需要重新安装，因为 npm 会从新路径查找命令。

8.2 迁移 npm 缓存目录

powershell复制npm config set cache "D:\dev\npm-cache"

设置后再执行：

powershell复制npm cache verify

这样 npm 下载的包缓存就不会写入 C 盘。

8.3 迁移 pip 缓存目录

Windows 下可以在用户环境变量中设置：

powershell复制setx PIP_CACHE_DIR "D:\dev\pip-cache"

设置后重启终端，再执行：

bash复制pip config list

如果输出里没有 global.cache-dir，可以用命令行指定：

bash复制pip config set global.cache-dir D:\dev\pip-cache

8.4 迁移 Codex 配置或日志目录

根据 Codex 的实际版本，可以在启动命令时指定环境变量，或者手动复制 ~/.codex 目录到 D 盘后用软链接指向它。软链接方式如下：

powershell复制# 先复制原有配置到 D 盘
Copy-Item -Path "C:\Users\<你的用户名>\.codex" -Destination "D:\dev\.codex" -Recurse

# 删除原目录（谨慎操作）
Remove-Item -Path "C:\Users\<你的用户名>\.codex" -Recurse

# 建立目录软链接
New-Item -ItemType SymbolicLink -Path "C:\Users\<你的用户名>\.codex" -Target "D:\dev\.codex"

这里要特别提醒：如果 .codex 里包含登录凭证和配置文件，删除前一定要完整备份。建立软链接后，Codex 仍然会按照原路径读写，但实际文件存放在 D 盘。

8.5 迁移虚拟内存或休眠文件？

虚拟内存页面文件 pagefile.sys 和休眠文件 hiberfil.sys 也可能占用几个 GB 到几十 GB。虚拟内存可以在“系统属性 -> 高级 -> 性能设置 -> 高级 -> 虚拟内存”中调整到 D 盘。休眠文件则可以通过 powercfg /h off 关闭，但如果你需要休眠功能，不建议关闭。

这里需要克制：虚拟内存迁移到 D 盘可以减少 C 盘占用，但不要为了腾空间把虚拟内存设得太小，否则系统在大负载任务时可能不稳定。

8.6 WSL 虚拟磁盘迁移

如果你使用 WSL，那么 ext4.vhdx 通常默认存放在 C:\Users\<用户名>\AppData\Local\Packages\... 下面，可能占用几十 GB。可以通过 WSL 的导入导出功能迁移到 D 盘：

bash复制wsl --export <分发名称> D:\dev\wsl-backup.tar
wsl --unregister <分发名称>
wsl --import <分发名称> D:\dev\WSL\Ubuntu D:\dev\wsl-backup.tar

注意：wsl --unregister 会删除当前分发中的所有数据，导出备份后一定要确认备份文件非空再继续。

8.7 Docker 数据目录迁移

如果你用 Docker Desktop，默认的 WSL 数据文件同样很大。可以把 Containers 和 images 相关的 WSL 虚拟磁盘迁移到 D 盘，或至少执行：

bash复制docker system prune -a --volumes

这条命令会清理未被任何容器使用的镜像、网络、构建缓存和卷。执行前必须确认当前没有需要保留的本地镜像。

9. 最佳实践与工程建议

9.1 清理前先备份

删除或迁移任何目录之前，先问自己三个问题：

1. 这个目录是系统、软件还是用户数据？
2. 删除后软件还能不能重新生成？
3. 如果是用户数据，有没有备份？

临时目录、缓存目录可以重新生成，可以删除；但 .codex、Docker 卷、虚拟机磁盘、数据库数据目录，必须有备份才动。

9.2 用磁盘分析工具辅助判断

不要只靠肉眼猜。Windows 自带的“存储设置”可以看一级分类，也可以使用第三方工具如 WizTree 或 TreeSize 来快速扫描磁盘大目录。这类工具经常能在一分钟内给出完整的目录大小视图。

9.3 让 Codex 帮忙写清理脚本，但不要让它执行危险命令

Codex 可以帮你生成扫描脚本、清理脚本，但你最好人工检查每一个要执行的命令。尤其是涉及 del、rm -rf、Remove-Item -Recurse 的命令，执行前确认路径变量没有问题，避免路径为空时误删根目录。

9.4 建立定期巡检制度

C 盘空间不是清理一次就结束的。建议每个月做一次这样的检查：

powershell复制# 查看 C 盘剩余空间
Get-PSDrive C

# 查看 Temp 大小
(Get-ChildItem "$env:TEMP" -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum / 1GB

如果发现某个缓存目录增长速度异常，就及时调整配置。

9.5 项目文件默认放到数据盘

在开发环境里，所有代码项目统一放在 D:\projects 或 D:\code，别让编辑器插件把项目索引和大文件缓存写到 C 盘。很多编辑器支持配置工作区存储路径，看到相关选项时顺手改到 D 盘，后期能省很多事。

9.6 注意最小权限与安全边界

清理时不要使用“管理员权限”无脑删除所有文件。有些目录的 ACL 权限是系统保护机制，强制篡改可能导致程序崩溃甚至系统不稳定。尽量以当前用户身份清理用户目录，涉及 C:\Windows 等系统目录时，优先使用系统自带的“磁盘清理”和“存储感知”。

9.7 关注 Codex 配置中的未识别项

Codex 版本迭代很快，配置项也可能频繁变化。如果启动时出现“ignoring 1 unrecognized configuration setting”这类提示，不要忽略它。查看配置文件，注释掉无法确认的项，再重新启动，避免因为配置错误导致模型调用异常。

9.8 不要迷信“一键清理”

很多 C 盘清理软件会扫描注册表、系统缓存、浏览器记录，然后向你推销“深度清理”。实际效果不一定比手动清理更好。与其安装一个大而全的工具，不如理解自己的系统里什么能删、什么不能删。

10. 关于 Codex 接入 DeepSeek 等第三方模型的说明

从近期的热词来看，不少人会关注“Codex 接入 DeepSeek”这类需求。这里要说明一下：Codex 官方配置通常针对 OpenAI 官方 API。如果你想把它接入第三方模型服务，通常需要修改配置文件中的 API Base URL、模型名称、认证方式等。

但有一条务必注意：模型名称不是随便填的。不同模型服务支持的能力不同，Codex 作为一个 agent 工具，对模型的函数调用、工具调用和长上下文能力要求较高。如果模型不支持这些能力，即使配置能通过，实际执行任务时也会报错。

一个更稳妥的做法是：先查看 Codex 配置文件，确认它支持的模型列表和 API 端点格式，再根据第三方服务商提供的信息做兼容。如果第三方服务没有明确说明“支持 Codex CLI”，就不要默认它能跑通。

11. 总结与后续学习方向

这篇文章的核心思路可以概括成一句话：C 盘空间问题的本质不是“空间不够”，而是“默认路径策略不合理”。Codex 作为 AI 编程工具，解决了代码生成和任务执行的问题，但它和很多开发工具一样，会在默认情况下把缓存和日志写入系统盘。要想长期保持 C 盘健康，必须理解目录结构、缓存机制和迁移方法。

下一步你可以做三件事：

1. 把 Codex 安装好，用它生成一个真实项目中的小工具，比如日志分析、文件扫描、批量重命名。
2. 用磁盘分析工具或脚本找出 C 盘的大目录，把 npm、pip、WSL、Docker 等缓存迁移到 D 盘。
3. 给自己定一条规矩：新安装的开发工具，先看它的配置路径和缓存路径，能改的立刻改。

如果能做到这三点，你的 C 盘大概率不会再红得那么快。就算以后再遇到“C 盘满了”的情况，你也不再需要到处找清理软件，因为你已经知道该去哪里看、该删什么、该改什么。

这篇内容里的命令和脚本，建议先找一个测试目录跑一遍，理解效果后再用于自己的电脑。删除和迁移目录前，记得备份数据。保持这个习惯，清理 C 盘就是一件非常安全且高效的事。