Node.js 项目从初始化那一刻起，包管理工具就决定了依赖如何被解析、安装、缓存和隔离。npm、yarn 与 pnpm 虽然都能完成安装依赖这件事，但底层机制差异很大，这种差异最终会反映在项目体积、安装速度和故障排查上。有人把 npm 当作默认选择，有人喜欢 yarn 的锁文件稳定性，还有人更看重 pnpm 的严格依赖与磁盘占用。要做出选择，需要先看清它们在依赖结构上的本质不同。
下面从安装机制、性能、锁文件与工作区几个维度展开分析。
一、安装机制与依赖结构差异
npm 在早期版本采用嵌套式 node_modules，一个包依赖其它包时会在自己的 node_modules 下继续存放依赖。这样虽然结构清晰，但路径过长，Windows 上还可能超过路径长度限制。从 npm v3 开始，npm 改为扁平化安装，把依赖尽量提升到顶层 node_modules。yarn 1 也采用类似的扁平化策略。这种做法的好处是减少重复，但代价是项目可以直接引用未在 package.json 中声明的包，这就是常说的幽灵依赖。假设 A 依赖 B，B 依赖 C，扁平化后 C 可能被提升到顶层，代码里直接 require C 也不报错；一旦 B 不再依赖 C，项目就可能在升级后突然崩溃。
pnpm 走的是另一条路线。它使用全局内容寻址存储保存每个版本的包，项目 node_modules 中的文件并不直接拷贝真实文件，而是通过符号链接和硬链接指向 .pnpm 虚拟存储目录。在 pnpm 管理的项目里，只有 package.json 中声明的依赖会出现在顶层 node_modules，每个依赖自己内部的依赖被隔离在 .pnpm 对应目录下。这样既节省磁盘空间，又从机制上避免了幽灵依赖，因为应用代码无法再直接 require 未声明的间接依赖。
下面是一个 pnpm 项目 node_modules 的简化结构示例：
node_modules
├── express -> .pnpm/express@4.18.2/node_modules/express
└── .pnpm
├── express@4.18.2
│ └── node_modules
│ ├── express
│ └── body-parser
└── body-parser@1.20.0
└── node_modules
└── body-parser
可以看到，pnpm 把 express 暴露在顶层，而 body-parser 只存在于 .pnpm 目录中，应用代码无法直接通过 node_modules 顶层路径访问它，除非它也被声明为直接依赖。这种严格性在大型项目中能减少隐蔽依赖带来的维护成本。
二、安装速度、缓存与磁盘占用
安装速度不只取决于网络，还和缓存命中、文件写入方式有关。npm 和 yarn 默认都为每个项目复制依赖文件，即使多个项目使用完全相同的依赖版本，也会各自占用一份磁盘空间。yarn 在缓存和并行下载方面比 npm 更早做了优化，所以很长一段时间里安装速度优于 npm。npm 后续版本逐步改进，但在大型项目中仍可能需要更多时间。
pnpm 在这一环节优势明显。全局 store 保存了所有已下载的包版本，项目安装时如果发现版本已经存在，就直接创建硬链接，不额外复制内容。这样多个项目可以共享同一份底层文件，磁盘占用显著下降。对于一些频繁创建前端项目的开发者来说，pnpm 能省下几个 GB 甚至更多空间。在 CI 场景中，如果配合持久化缓存，pnpm 的安装速度通常也快于 npm 和 yarn。
下面从几个关键维度做简单对照：
| 维度 | npm | yarn | pnpm |
|---|---|---|---|
| 依赖结构 | 扁平化 node_modules | 扁平化 node_modules | 符号链接与硬链接 |
| 默认锁文件 | package-lock.json | yarn.lock | pnpm-lock.yaml |
| 磁盘占用 | 较高 | 较高 | 较低 |
| 安装速度 | 较快 | 较快 | 通常更快 |
需要注意的是，yarn 2 及之后的 Berry 版本提供了 PnP 模式，可以通过 .pnp.cjs 文件替代 node_modules，但部分工具和 IDE 对 PnP 的支持并不完善。相比之下，pnpm 保留了 node_modules 目录结构，同时降低磁盘占用，在兼容和性能之间取得了更平衡的结果。
三、锁文件、依赖一致性与 Monorepo 工作区
锁文件的作用是固定依赖解析结果，保证不同机器安装到相同版本。npm 的 package-lock.json 会记录依赖树结构和版本，yarn.lock 的可读性和稳定性一直不错，pnpm-lock.yaml 则适合 pnpm 的严格依赖模型。团队协作时，只要提交锁文件，就应避免频繁更换包管理工具或手动修改锁文件，否则容易造成版本漂移。
Monorepo 是包管理工具选型的重要考量。npm 从 v7 开始内置 workspaces，可以在 package.json 中声明多个 package 目录；yarn 的 workspaces 出现更早，在大型前端仓库中应用广泛；pnpm 则有独立的 pnpm-workspace.yaml 配置，支持 --filter 按包执行命令。下面是一个 pnpm 工作区配置示例：
packages: - packages/* - apps/*
在这个配置下，apps/admin 和 packages/ui 等目录会成为独立工作区，共享锁文件和依赖解析结果。yarn 和 npm 也有类似能力，但 pnpm 在依赖隔离上的严格性使得子包之间不会互相意外引用，这对大型 Monorepo 的边界管理很有帮助。
如果你需要从 npm 迁移到 pnpm，可以使用 pnpm import 读取现有 package-lock.json 生成 pnpm-lock.yaml。从 yarn 切到 pnpm 也可以先清理 node_modules 再安装。迁移过程中可能会遇到部分包依赖未显式声明但在 npm 的 node_modules 下能正常工作的情况，这时候通常需要补全依赖或调整导入方式，这恰恰暴露了原有的幽灵依赖问题。
四、选型建议：根据场景做出判断
如果项目只是个人练习、原型验证或依赖简单的内部工具，npm 仍然是最省心的选择。它是 Node.js 自带工具，不需要额外安装，文档和社区反馈也最容易找到。对于已经深度使用 yarn 1 的团队，如果没有明显痛感，继续使用 yarn 并维护锁文件也可以，但如果正在规划大型 Monorepo，可以考虑 pnpm。
当你的关注点在磁盘占用、安装速度和依赖严格性上，pnpm 是更现代的选择。它特别适合频繁创建新项目、需要多项目共享缓存或对依赖边界有严格要求的团队。pnpm 的命令大多与 npm 类似，例如 pnpm install、pnpm add、pnpm remove、pnpm run，学习和迁移成本不高。
最终不必追求绝对最优，而要结合团队熟悉度、现有 CI 配置和生态兼容性。可以先用一个新分支尝试 pnpm，运行测试和构建脚本，确认所有依赖都能正常解析后再决定是否全面切换。无论选哪一个工具，都要提交锁文件，并在团队内统一约定，避免混用造成依赖树不一致。