如何清理开发工具缓存，又不破坏构建

开发环境的空间分散在软件包下载、构建输出、SDK、本地数据库和项目依赖树中，部分可以重建，部分依赖锁文件、软件源和工具链，还有一些是唯一的本地数据。点号目录只说明它被隐藏，并不说明它是缓存。

查看各工具的全局存储

du -sh ~/.npm ~/.cargo ~/.cache/pip ~/Library/Caches/pip ~/.gradle 2>/dev/null | sort -h

这些只是默认位置。尽量用工具查询实际路径，例如 npm config get cache、python -m pip cache dir 和 pnpm store path。

• npm： 默认缓存位于 ~/.npm。先运行 npm cache verify。npm 缓存可以自我修复，npm cache clean --force 只适合明确的空间回收或故障排查
• Cargo： ~/.cargo 不只有缓存，还可能包含已安装二进制文件、配置、软件包记录与注册表凭据。当前 Cargo 会定期清理未使用缓存，手动处理时也应落到具体子目录，整体删除会把这些非缓存内容一起带走。详见 Cargo home
• pip： 默认缓存 wheel 和 HTTP 响应到 ~/Library/Caches/pip。python -m pip cache info 显示实际位置与大小，python -m pip cache purge用于清空
• pnpm、yarn： 可用 pnpm store prune 和 yarn cache clean处理未引用或缓存包。先确认版本，因为存储布局和本地、全局行为会变化
• Gradle、Maven： ~/.gradle 和 ~/.m2 可能很大。Gradle 已有定期缓存清理，手动检查前可以先停止守护进程，Maven 仓库还可能含有本地构建或私有产物，整库删除会失去这些唯一副本

清掉这些内容可能触发大型下载、原生代码重编译，甚至让已经从软件源消失的历史版本无法构建。称它为可重建之前，先确认锁文件、软件源和工具链仍然可用。

找出散落的 node_modules

真正占空间的往往不是一个全局缓存，而是多个旧项目各自的 node_modules。每个目录常有 200 至 500 MB，累积起来很可观。

find ~/www ~/Projects -name node_modules -type d -prune -exec du -sh {} + 2>/dev/null

把示例根目录换成实际项目位置。-prune 避免继续进入依赖树，-exec 能正确处理路径中的空格和特殊字符。

项目能否重建依赖，取决于源码、锁文件、软件包管理器版本、注册表访问和原生工具链。保留这些输入后，使用与锁文件对应的命令，例如 npm ci。

这些内容不能当缓存删

项目源码和 package.json、package-lock.json、Cargo.lock 等锁文件定义了构建，不是缓存。全局共享存储正在被安装使用时也不能清理，否则可能损坏索引。先停止构建、安装和相关守护进程。

共享存储和项目依赖树不同

pnpm 会在全局内容寻址存储中保留软件包版本，再通过硬链接接入各项目的 node_modules，多个项目可以共享同一份磁盘内容。Cargo 和 Go 缓存也常按版本或校验和组织。

传统 npm 安装则会在每个项目中生成依赖树。因此，删除一个项目的 node_modules 与清理全局共享存储，影响范围完全不同。内容寻址能去重和校验，却不能保证未来仍能从软件源下载同一版本。

Mole 的「分析」页可以找出哪个项目或存储最大，软件包管理器自己的 verify、prune 和 clean 命令则理解索引与引用。先用地图选目标，再由所属工具执行清理。

比较容易复核的顺序是：停止构建和守护进程，测量选定目录，验证软件包存储，保留源码与锁文件，再处理依赖树。文档中的 prune 或 clean 命令通常比删除整个点号目录更了解引用关系，清空废纸篓前，也可以用一个重要项目的完整构建确认输入仍然齐全。