npm 与 pnpm 缓存：藏在 AppData 里的几个 GB

两个工具，两种缓存模型

npm 在 %LOCALAPPDATA%\npm-cache 维护一个按内容寻址的缓存：每个下载过的 tarball，外加日志和供一次性运行包使用的 _npx 缓存。已装项目的运行完全用不到这些，它们存在的意义只是让以后的安装更快、离线可用。pnpm 的思路不同：一个全局仓库（较新版本位于 %LOCALAPPDATA%\pnpm\store）保存真正的文件，每个项目的 node_modules 都由指回它的硬链接搭建而成。所以 pnpm 项目不会像 npm 项目那样成倍放大磁盘占用——也因此仓库本身无上限增长：每个新包版本都会永久沉积在那里，直到你修剪。

结果就是那个熟悉的意外：你删掉一个老项目，空间却没回来，因为仓库里的硬链接让数据继续活着。该检查的是仓库，而不是项目文件夹。

值得记住的清理命令

以下命令在设计上都是安全的——缓存就是缓存，工具会按需重建：

npm cache clean --force —— 清空整个 npm 缓存；下次安装会重新下载所需内容
npm cache verify —— 温和选项：做垃圾回收和完整性校验，而不是一锅端
pnpm store prune —— 从仓库移除不再被任何项目链接的包
删除 %LOCALAPPDATA%\npm-cache\_npx —— npx 运行的一次性缓存，随时可删
npm config set cache D:\dev\npm-cache —— 把缓存从系统盘永久挪到数据盘
先测量：对 AppData 做一次体积扫描胜过盲目删除——npm-cache 和 pnpm 仓库就是那两个惯犯

NTFS 硬链接陷阱

这是让所有人困惑的部分：在 NTFS 上，只有当指向文件数据的最后一个硬链接消失时，数据才会被释放。清理完 node_modules 之后立刻删 pnpm 仓库，你能如预期般释放空间；而在项目还链接着仓库文件时删掉它，你什么都释放不了——只要 node_modules 还在，字节就留在磁盘上，资源管理器也会继续显示那些实际已成空壳的仓库条目。所以顺序很重要：先移除项目（或它们的 node_modules），再运行 pnpm store prune。每月做一次这件事，收益最大的是 CI 运行机和批量消化大量仓库的机器；在只有一个项目的笔记本上，仓库很少值得这份关注。