node_modules 之战：从废弃的业余项目里夺回几个 GB

磁盘上每个死掉的业余项目都给自己立了座纪念碑：一个文件数比 Windows 安装还多的 node_modules 文件夹，有时还带着几个 GB。好消息是，删掉它们不但安全，本来就是这套体系的设计意图。下面是把空间拿回来、又不弄坏你还在乎的东西的完整流程。

为什么一个文件夹能比操作系统还重

npm 会把所有依赖装进每个项目各自的本地 node_modules，默认情况下项目之间既不共享也不去重。一个不起眼的 Web 应用轻松拉来 800 MB 到 2 GB、上千个包，而真正的杀手是文件数量：几万个碎文件，Windows Defender 要扫描、备份工具要爬行，如果你把项目放在同步文件夹里，OneDrive 会永远噎在那里。Windows 上安装要几分钟而 Linux 只要几秒，也是同一个原因：创建海量小文件的开销太狠。五个废弃实验之后，你面对的就是 10–15 GB 没有任何东西在用的数据。

放心删：lockfile 就是你的担保

契约很简单：package.json 说明你需要什么，package-lock.json 记录你当时用的确切版本，而 node_modules 只是这两者解包后的产物。删掉 node_modules，跑一遍 npm ci，几分钟后一模一样的依赖树就会回来。这不是什么抢救技巧，而是预设的工作流。唯一不可饶恕的错误是删掉 lockfile，或者放任项目在没有提交 lockfile 的状态下烂掉。查找文件夹可以用 npx npkill：它会扫描所有磁盘，列出每个 node_modules 的大小和最后修改时间，并删除你标记的项。想要全局视野的话，WizTree 可以作为通用磁盘地图干同样的活。

删 node_modules——永远别删 package.json 和 lockfile
用 npm ci 重装：它严格按 lockfile 执行，npm install 做不到
运行 npx npkill，找出并清剿所有磁盘上的 node_modules
活跃项目别放进 OneDrive 和 Dropbox 文件夹——文件数量会拖垮同步
项目死了？先压成不含 node_modules 的 zip，再删文件夹
新项目试试 pnpm：一个全局仓库，各项目链接过去

文件夹背后的缓存

就算所有 node_modules 都没了，npm 还藏着第二座仓库：%LOCALAPPDATA%\npm-cache 里的缓存保存着你装过的每个包的每个版本，而且年复一年单调增长。npm cache verify 可以安全地收拾它，同样的逻辑也适用于 pnpm store prune 和 yarn cache clean。npm 缓存本身值得保留：正是它让“空缓存重装项目”成为少数的慢路径而不是常态。Kleaner PRO 的定期垃圾清扫会把这些开发者缓存和常规临时文件一并带走，在多个工具悄悄囤货的同一台机器上尤其有用。