为什么依赖目录增长得这么快
前端工具链会拉取大量小文件和平台二进制。monorepo、Electron、Playwright 或包含原生模块的项目尤其明显。旧项目即使不再打开，依赖目录也不会自动消失。
不要只搜索名为 node_modules 的目录数量；应按实际占用排序。某个近期项目可能有多个工作区，真正占用比顶层目录看起来更大。
删除前确认可重建条件
保留 package.json 与对应的 package-lock.json、pnpm-lock.yaml 或 yarn.lock，并确认私有 registry 仍可访问。若项目依赖已经下线的包、未提交补丁或本地链接，删除后不一定能恢复到原状态。
先提交工作区变更或保存补丁。对需要离线演示的项目，不要在出差前清依赖；网络、Node 版本和原生编译环境都会影响重新安装。
选择性清理旧项目
优先删除已归档、已合并或数月未打开项目中的 node_modules。活跃项目里可先清理构建输出与工具缓存，避免每次都支付完整安装时间。
Diskly 的目录树图能让由大量小文件组成的依赖目录显示为一个汇总块。找到目标后在 Finder 中显示，逐个确认项目状态，不建议对整个用户目录运行未经检查的递归删除命令。
减少未来的重复占用
统一团队包管理器并使用 lockfile；pnpm 的内容寻址存储可减少相同包的重复副本，但全局 store 也需要按官方命令维护。定期归档不再活跃的项目，并在项目说明中写清 Node 与包管理器版本。
清理后用锁文件的严格安装模式验证一次，例如 npm ci 或对应工具的 frozen-lockfile 选项，确认项目确实可以恢复。