「我有47个node_modules文件夹，总共38GB。大多数项目我已经几个月没碰过了。」一位开发者在清理Mac时发现，去年周末学的教程、 abandoned 的side project、只打开过一次的克隆仓库——全都在硬盘里默默膨胀。
如果你也是JavaScript开发者，Mac反复提示磁盘已满，元凶很可能不是照片、不是音乐，而是分散在几十个遗忘项目目录里的20万个小文件。
本文将拆解node_modules的膨胀机制，并给出可立即执行的清理方案。
为什么三个依赖能变成900MB
node_modules的体积失控并非偶然，而是npm架构设计的结构性结果。
npm v3引入扁平依赖树（flat dependency trees），本意是解决Windows上路径过深的问题。代价是：每个传递依赖都被提升到node_modules顶层。安装create-react-app，你会得到1400多个平铺的包。你的项目依赖5个东西，这5个东西依赖1395个其他东西——全部挤在你的项目文件夹里。
更隐蔽的问题是跨项目重复。10个React项目意味着10份完整的React、10份webpack、10份TypeScript。没有跨项目去重机制，每个node_modules都是孤岛。
典型React项目的node_modules约300-500MB，Next.js项目可达600MB-1GB。乘以机器上的所有项目，20-50GB悄无声息地消失。
原生二进制文件进一步加剧膨胀。esbuild、swc、sharp、better-sqlite3、Playwright的浏览器二进制文件，单个常达50-200MB。它们在npm install时下载平台特定版本，体积不容小觑。
此外，构建输出目录同样暗藏玄机：dist、build、.next、.nuxt、out。Next.js的构建缓存（.next）单项目即可达200-500MB，与node_modules一样可安全删除——下次构建时重新生成。
定位硬盘里的所有node_modules
删除前，先看清损失范围。以下命令查找主目录下所有node_modules并显示大小：
find ~ -name "node_modules" -type d -maxdepth 5 -exec du -sh {} \; 2>/dev/null
典型输出示例：
1.2G /Users/you/projects/webapp/node_modules
487M /Users/you/projects/api-server/node_modules
923M /Users/you/code/nextjs-blog/node_modules
341M /Users/you/tutorials/react-course/node_modules
756M /Users/you/clients/dashboard/node_modules
maxdepth 5限制递归深度，避免扫描node_modules内部的node_modules（某些旧版npm的嵌套残留）。2>/dev/null屏蔽权限错误提示。
执行后你会得到一份清晰的「罪状清单」——哪些项目仍在活跃，哪些只是数字遗迹。
安全删除与预防策略
删除node_modules的风险极低：它是纯依赖目录，不含源代码，npm install可完全重建。真正的决策在于判断哪些项目值得保留。
建议按时间维度分层处理：
• 超过6个月未触碰的教程/实验项目 → 直接删除整个项目目录
• 有代码价值但暂时搁置的项目 → 仅删除node_modules，保留源码
• 活跃项目 → 保留，但考虑迁移至统一依赖管理
长期预防需要工具介入。pnpm通过内容寻址存储实现跨项目去重，同一依赖的多个版本只存一份物理副本。Yarn的Plug'n'Play模式则彻底取消node_modules目录，改为全局缓存加虚拟映射。
对于必须维持npm的场景，可建立定期清理脚本，或采用Docker容器化开发环境——项目结束后整个容器销毁，不留痕迹。
38GB的47个node_modules文件夹，本质上是前端开发生态「即用即走」文化与物理存储持久性之间的摩擦。每个被遗忘的依赖树都是技术决策的化石：那个周末想学的新框架，那个只跑了两次的脚手架，那个「以后可能会用」的克隆仓库。
当硬盘空间成为约束条件，开发者被迫面对一个事实：node_modules的设计假设——每个项目独立、完整、自包含——在个人机器尺度上并不经济。而社区给出的解决方案——pnpm的去重、Yarn的零安装、Docker的隔离——都在重新定义「本地开发环境」的边界。
清理命令执行完毕的那一刻，你回收的不只是空间，还有对技术债务的可见性。那些具体数字——1.2G、487M、923M——比任何抽象警告都更能说明问题。
热门跟贴