如果 npm 缓存和旧的 node_modules 文件夹正在占用 Mac 大量空间，请先区分共享的 npm 缓存和项目本地的依赖。在清除缓存之前先审查它，然后只在准备好重新安装或不再需要该项目时才删除过期的 node_modules 文件夹。
这个区分很重要，因为 npm cache 和 node_modules 解决的是不同的问题，它们的清理后果也不同。
一个是可复用的包缓存，另一个是你的项目实际运行所依赖的依赖树。把它们当作一个可以随意丢弃的整体来处理，正是许多开发者快速回收空间后又因重建错误环境而浪费时间的原因。
核心原则：清理共享缓存以回收空间。仅在项目级别的重建成本可接受时才移除 node_modules。
快速回答
- 检查实际问题来源是
~/.npm、项目级别的node_modules，还是两者兼有。 - 在直接执行完整缓存清除之前，先使用
npm cache verify。 - 仅当回收磁盘空间的价值超过重新下载的成本时，才使用
npm cache clean --force。 - 只在可以安全重新安装或不再活跃使用的项目中删除
node_modules。 - 在处理活跃工作区之前，先审查旧仓库、已归档分支和废弃的示例项目。
- 如果 npm 只是问题的一部分，按生态系统而非仅按文件夹大小来审查开发者存储。
node_modules 在空间压力上看起来相似，但它们不是同一个清理决策。
为什么 npm 缓存和 node_modules 在 Mac 上增长如此之快
JavaScript 开发者的机器很少只因一个项目而膨胀。真正的模式是积累。
你在多个应用、分支、原型和客户端仓库中安装包。npm 维护一个可复用的缓存，这样安装就不需要每次都从网络获取所有内容。每个项目也在自己的 node_modules 中保留本地依赖树。
这意味着磁盘增长可以从两个方向同时发生：
- 共享的 npm 缓存随着你安装新包和新版本而不断扩大；
- 多个项目文件夹，每个都有自己的
node_modules树； - 旧仓库中重复或近乎重复的依赖；
- 原生模块和工具链包即使理论上可丢弃，也会增加重建成本；
- 从未被归档、删除或干净重装的过期项目。
结果很熟悉：一个仓库令人烦恼，十个仓库代价昂贵，一年的正常工作悄然变成了一个存储问题。
npm 缓存 vs node_modules：有什么区别？
这是最重要的区分。
根据 npm 官方文档，缓存文件默认存放在 Posix 系统的 ~/.npm 目录下，而本地安装则放入当前包根目录下的 ./node_modules。npm 先将包加载到缓存中，然后解压到需要它们的项目的 node_modules 中。
| 项目 | Mac 上的典型位置 | 用途 | 默认安全？ | 主要清理后果 |
|---|---|---|---|---|
| npm 缓存 | ~/.npm | npm 使用的共享包下载缓存 | 通常安全，如果目标是回收磁盘空间 | 未来的安装可能需要重新下载包 |
| node_modules | project-root/node_modules | 特定项目的已安装依赖树 | 视上下文而定 | 项目需要重新安装、重建或重新链接才能正常运行 |
这就是为什么”npm 占用了空间”通常太模糊而无法操作。你需要知道压力来自共享缓存、旧的项目安装，还是两者兼有。
npm 官方文档的启示
npm 缓存被设计为缓存，而不是项目的工作依赖树。npm 明确将其文档化为一个可以后续重新填充的缓存。
node_modules 则不同。这个文件夹是你的项目包、可执行文件和本地依赖图实际存放的地方。如果你移除它，你不仅仅是在清除缓存——你正在移除项目当前使用的已安装依赖。
在 Mac 上删除 npm 缓存安全吗？
通常安全，但原因很重要。
npm 官方文档说缓存经过完整性验证，清除它通常仅在目标是回收磁盘空间时才必要。这是一个重要的框架差异。npm 缓存不应被视为珍贵状态，但它也不是你需要仅仅因为存在就定期清除的东西。
安全的心智模型是：
- 如果你的 Mac 空间紧张，缓存清理可以是一个合理的权衡；
- 如果你的安装正常工作，清除缓存通常没有必要；
- 如果你清除了它，预计后续安装需要重新下载包；
- 如果你只想先检查缓存状态，使用
npm cache verify。
更好的第一步：先验证再清除
npm 将 npm cache verify 文档化为对现有缓存内容的离线验证步骤。这使得它成为你在回收空间之前进行低风险检查时的更好首选命令。
npm cache verify如果你的目标明确是释放磁盘空间，npm 文档化的清理命令是：
npm cache clean --force--force 标志是设计上要求的。npm 将缓存清除视为一个有意的磁盘空间决策，而不是日常维护习惯。
在 Mac 上删除 node_modules 安全吗？
有时可以，但这正是上下文更加重要的地方。
删除 node_modules 会移除该项目的本地依赖树。如果项目是活跃的，直接后果通常很明显：脚本找不到包，本地可执行文件从 node_modules/.bin 中消失，下一次安装或构建可能比你预期的更耗时。
这不意味着你永远不应该移除它。它意味着你应该有意识地移除它。
删除 node_modules 的好候选：
- 你不再活跃运行的旧项目；
- 可以稍后重建的过期示例或原型；
- 你打算干净重装的仓库；
- 有可靠 lockfile 且重装是可预期、可接受的项目。
高摩擦情况：
- 在截止日期、演示或发布构建前的活跃工作仓库；
- 包含需要时间重建的原生模块的项目；
- 你几个月没碰过、可能不记得如何快速恢复的工作区；
- 没有干净依赖方案或缺少预期 lockfile 的仓库。
项目清理原则：删除 node_modules 是工作区重置，而不是无害的缓存修剪。
为什么旧的 node_modules 文件夹造成的伤害这么大
一个项目尚可管理。真正的浪费来自拥有大量项目。
每个旧仓库都可能保留一个完整的依赖树、包管理器元数据、可选的原生包、框架工具链和特定版本的构建产物。这就是为什么开发者经常认为 npm 是问题所在，而更大的罪魁祸首实际上是一堆被遗忘的、分散在已废弃仓库中的 node_modules 文件夹。
如何手动清除 npm 缓存
如果你想要手动方式，保持精确和明确。
1. 检查当前缓存目录
如果你曾在某个时候更改过 npm 配置，你的缓存可能不在默认位置。先查询 npm：
npm config get cache2. 在删除之前先验证缓存
先使用文档化的验证步骤：
npm cache verify3. 仅在你确实想要回收空间时才清除缓存
如果回收磁盘空间值得后续的重新下载：
npm cache clean --force4. 如有需要，重新检查大小
一旦你知道缓存路径，可以直接检查其大小：
du -sh "$(npm config get cache)"这是更安全的顺序，因为它将位置、验证和清理分为不同的决策。
在删除之前如何查找旧的 node_modules 文件夹
这通常是更高价值的清理操作。
从你不再活跃构建的项目开始。这比在 Finder 中盲目追逐单个最大文件夹更重要。
使用这样的审查顺序：
- 在主项目目录中搜索
node_modules文件夹。 - 检查哪些仓库是过期的、已归档的或容易重装的。
- 确认该项目本周是否仍需要在本地运行。
- 只删除那些你理解重建成本的
node_modules文件夹。
如果你想要终端辅助的审查，使用能在删除之前显示这些文件夹实际位置的命令：
find ~/Projects -type d -name node_modules -prune -print
find ~/Projects -type d -name node_modules -prune -exec du -sh {} +这仍然是手动的，但比凭情绪对一个巨大的工作文件夹做出反应要好。
在删除项目的 node_modules 之前要审查什么
- 仓库是否仍然活跃？
- 你是否有预期的 lockfile？
- 是否有原生模块或代码生成步骤使重装变慢？
- 项目是否是你不想随意干扰的 monorepo 或工作区设置的一部分？
- 归档或删除整个废弃项目是否是比仅移除
node_modules更好的清理方式？
通常最强的清理操作不是”到处清除依赖”，而是”删除你不再需要的旧项目”。
yarn、pnpm 和 bun 的缓存呢？
将这部分与 npm 分开处理。
如果项目使用其他包管理器，使用该包管理器自己的清理模型，而不是假设 npm 命令可以直接套用。
Yarn
现代 Yarn 将 yarn cache clean 文档化为移除共享缓存文件的命令。它还提供了 --mirror 和 --all 选项用于更广泛的清理范围。
yarn cache cleanpnpm
pnpm 使用 store 模型而非 npm 的精确缓存模式。pnpm 官方文档将 pnpm store prune 描述为从 store 中移除未被引用的包，并指出未来的安装可以在需要时重新下载被移除的包。
pnpm store pruneBun
Bun 将全局包缓存文档化为默认位于 ~/.bun/install/cache。它的文档还指出包在下载后仍然会复制到 node_modules 中，所以 Bun 如果你只看文件夹大小，也会产生同样的”缓存加项目安装”混淆。
重要的部分不是记住每个命令，而是避免混合存储模型。npm 缓存、Yarn 缓存、pnpm store 和 Bun 缓存是相关问题，但不是完全相同的问题。
为什么按生态系统审查让开发者清理更安全
node_modules 很少是 Mac 上唯一开发者存储问题。它通常与 Xcode 数据、模拟器存储、Docker 镜像、构建缓存、日志和其他工具链特定的路径并列存在。
普通的文件浏览器能显示一个文件夹很大。它不能告诉你那是：
- 可重建的 npm 缓存；
- 活跃的工作区依赖树；
- pnpm store；
- Docker 缓存；
- 还是恰好位于你项目附近的另一个生态系统。
这就是为什么当工作流保持感知生态系统时，开发者清理效果更好。
如果你的真实情况是”npm 加上 Docker 加上旧的 Xcode 数据加上太多过期仓库”，那种更全面的先审查模型比逐个追逐文件夹更有用。
总结
如果 npm 缓存和 node_modules 正在占用 Mac 大量空间，不要把它们当作同一个清理目标。
对共享缓存使用 npm cache verify，当回收空间是实际目标时使用 npm cache clean --force。逐个项目地审查旧的 node_modules 文件夹，只在你理解重装成本时才删除它们。
这是更安全的路径：将缓存与工作区状态分开，在处理活跃项目之前先审查过期项目，让开发者清理与生态系统上下文关联，而不是盲目删除文件夹。
常见问题
Mac 上的 npm 缓存是什么？
npm 缓存是 npm 在 Mac 上保存的本地包下载缓存，默认位于 ~/.npm 目录下（除非你修改了缓存配置）。它与项目依赖中存储在 node_modules 里的文件是不同的。
在 Mac 上删除 npm 缓存安全吗？
通常安全，前提是目标是回收磁盘空间。npm 官方文档将缓存定位为可重建的，并建议仅在空间回收是真正目的时才清除它，因为未来的安装会重新下载这些包。
在 Mac 上删除 node_modules 安全吗？
视情况而定，且需要结合上下文判断。删除 node_modules 会移除该项目的已安装依赖，所以你应该只在准备好重新安装、或者项目已经废弃到重建成本无关紧要时才执行此操作。
为什么旧的 node_modules 文件夹会占用这么多空间？
每个项目都可以保留自己的依赖树、构建相关的包、原生模块和特定版本的构建产物。跨多个仓库积累下来，这种重复的本地安装占用会迅速膨胀。
npm 缓存和 node_modules 有什么区别？
npm 缓存是 npm 的共享下载缓存，而 node_modules 是项目本地的依赖文件夹，你的应用实际运行时依赖它。一个是可复用的缓存，另一个是特定项目的已安装依赖树。