kok的笔记本：从 node_modules 瘦身看前端开发环境（wocai-blog-node-modules-pnpm）
一个常见的磁盘空间困扰
前端项目开发一段时间后，依赖目录可能占用数百 MB。多个项目并存时，重复安装的依赖会让磁盘使用不断累积；目录中大量小文件也会增加复制、删除、索引和安全扫描的负担。文章从这个熟悉的现象出发，强调排查时应进一步观察依赖树，而不是只看项目源代码大小。
开发环境通常由多类工具构成。TypeScript、打包器、测试环境、图片处理库和本地运行时服务于不同环节，一个构建工具还可能带入转译、兼容、日志和文件操作等间接依赖。因此，业务逻辑并非总是占用空间的主体。理解这一点，才能把清理工作放在真正的大目录和重复内容上。
依赖树为何容易膨胀
直接依赖只是清单的起点。安装程序还要解析它们各自需要的间接依赖，最终在项目中形成一棵更大的依赖树。不同构建工具、测试框架和开发服务器各自带有配套组件，叠加后会形成可观的磁盘占用。若多个项目使用相似的技术栈，常见包就可能在各自目录里重复出现。
版本差异会进一步影响复用。不同项目可能对同一包提出不同版本范围，最终解析出的版本也不完全一致。即使包名相同，只要内容版本有差异，就需要分别保留。文章还提醒读者注意目录结构带来的错觉：使用链接的包管理器时，顶层看到的目录大小不一定代表其实际数据量，应检查真正保存包文件的位置。
作者以三个项目目录为例，记录主项目、worker 和 website 的 node_modules 分别约为 262M、169M 和 147M。拆解后，较大的部分集中在 TypeScript、构建工具、Cloudflare 本地运行时、图片处理组件以及 Astro 相关工具链。这个案例说明，项目依赖目录的体积要结合工具用途理解，不能简单归因于源码写得太多。文章给出的数字是作者当时对自己项目的观察，不代表所有项目都会有相同构成。
pnpm 如何减少重复存储
文章把 pnpm 作为多项目开发场景的一种选择。其核心思路是把包内容放在统一的内容寻址存储中，再通过硬链接和符号链接组织项目所需的依赖。若多个项目需要相同版本，磁盘可以复用相同内容，避免每个项目完整保存一份。这种方式尤其适合本地维护多个 Node 项目、monorepo 或频繁创建实验项目的开发者。
这种复用并不会让依赖本身消失。项目仍有自己的依赖关系，只是相同文件可以从共享存储复用。pnpm 也采用较严格的依赖可见结构，能够让未在项目清单中声明、却偶然因扁平目录结构而可用的依赖问题更早暴露。对维护者来说，这可能意味着迁移时需要修复历史遗留的隐式依赖；对新项目而言，则有机会从一开始就保持依赖声明清晰。
从现有项目逐步迁移
文章中的迁移建议包括先评估项目和工具链，再决定新旧项目的切换节奏。对于新项目，可以选用 pnpm 并提交对应锁文件；对已有项目，则需要检查安装脚本、CI 配置和团队文档，确保日常安装方式一致。一个仓库最好明确采用一种包管理器，避免不同工具交替安装造成锁文件来回变化和依赖树漂移。
迁移时还要留意工具对符号链接的支持。有些较旧工具可能假设依赖目录采用传统的扁平结构，遇到兼容问题时需要查明具体原因，再考虑调整链接布局或工具配置。切换包管理器不应只执行一次安装命令就结束，还需要检查开发、构建和持续集成流程是否都能使用同一份依赖声明正常运行。
若目标只是临时腾出空间，文章建议先确认哪些子项目近期不会使用，再清理相应的依赖目录或构建产物。删除前应确认项目能够通过锁文件重新安装，并避免误删未备份的数据。这样做针对的是暂时占用；如果长期有多个项目重复安装相同依赖，则可以再考虑从存储机制和团队习惯上减少重复。
适用场景与迁移代价
当电脑中同时维护多个 Node 项目、常做 monorepo 开发、经常重装依赖或磁盘空间紧张时，跨项目复用更可能带来实际收益。如果只有一个很小的项目，团队已有稳定流程且工具链依赖特定包管理器，那么切换的收益可能有限。文章没有把 pnpm 描述成适用于所有场景的唯一答案，而是从重复依赖、目录体积和协作流程来判断是否值得采用。
严格的依赖结构也会揭示一些过去被隐藏的问题。如果代码使用了未声明的包，迁移后可能需要把它补充到项目配置中；如果工具不适应链接结构，则需要针对工具做兼容处理。团队还需要统一锁文件、文档命令与 CI 安装参数。把这些工作纳入迁移计划，能够减少开发者之间环境不一致造成的故障。
站点内容与阅读方式
kok的笔记本通过分类和系列文章组织不同主题，首页还呈现近期技术文章、系统问题观察和软件评测。读者可以从首页按时间浏览，也可以使用分类、系列文章或搜索入口寻找特定内容。文章保留个人实践的背景和具体目录数据，适合作为排查依赖占用时的思路参考；具体结论仍应结合自己的项目清单、锁文件和实际磁盘分析验证。
整体来看，这篇 node_modules 文章把问题从“文件夹为什么大”拆解到依赖来源、版本差异、重复存储和开发工具链，并以 pnpm 作为一种可选的管理方式。它既给出个人项目的数据，也讨论迁移中的严格依赖和工具兼容代价。对于维护多个前端或 Node 项目的读者，站点提供了一个从实际体验出发的技术记录入口。