pnpm 快速安装深度解析
## 关于 pnpm 快速安装的一些技术随想
最近在项目里重新用起了 pnpm，顺手整理了一些关于它的使用心得。如果你也在为 node_modules 的混乱和安装速度发愁，或许这些内容能给你一些参考。
它到底是什么
pnpm 的全称是 “performant npm”，字面意思就是“高性能的 npm”。但它的核心其实不在“快”这个表象上，而在于它处理依赖的独特方式。传统的 npm 或 yarn 在安装依赖时，采用的是“复制”策略。每个项目都会把依赖包完整地下载到自己的 node_modules 文件夹里。如果十个项目都用到了 lodash，那么磁盘上就会有十份 lodash 的副本。
pnpm 换了一种思路，它建立了一个全局的存储仓库。当你第一次安装某个版本的包时，它会下载并存储在这个全局仓库里。之后任何项目再需要这个包时，pnpm 不会复制文件，而是在项目的 node_modules 里创建一个“硬链接”，指向全局仓库里的那个原始文件。你可以把它想象成图书馆：书（依赖包）只买一本放在中央书库（全局存储），每个读者（项目）需要时，拿到的是这张书的“借阅卡”（硬链接），而不是自己去复印一本。
这样做最直接的好处就是节省磁盘空间。一个大型的 Monorepo 项目，依赖动辄几个G，用 pnpm 可能能省下 60%-70% 的空间。另一个不那么明显但很重要的好处是，它从机制上保证了依赖树的严格性，基本杜绝了“幽灵依赖”的问题。
它能解决什么问题
除了上面提到的节省空间，pnpm 在速度上的优势其实是个“副产品”。因为大部分包已经存在于全局存储中，所以安装过程省去了大量的网络下载和文件解压、复制的时间，尤其是在第二次及以后的安装中，速度提升非常明显。在 CI/CD 流水线里，配合缓存机制，构建速度的改善有时是决定性的。
它更深远的影响在于提升了依赖管理的“确定性”和“一致性”。由于采用了基于内容寻址的存储和符号链接的组织方式，项目的 node_modules 结构几乎是完全扁平和可预测的。这解决了传统 npm 中可能出现的依赖提升不一致、不同环境下安装结果不同等恼人问题。对于需要严格保证环境一致性的团队来说，这个特性价值很大。
怎么开始使用它
安装 pnpm 本身非常简单。官网推荐了几种方式，最通用的是通过 npm 来安装：npm install -g pnpm。当然，你也可以用独立脚本或者包管理器来装，看个人习惯。
安装好后，它的命令行用法和 npm 高度相似，学习成本几乎为零。常用的pnpm install,pnpm add <package>,pnpm run <script>和 npm 的命令是一一对应的。如果你之前用 npm 或 yarn，几乎可以无缝切换。第一次在项目里执行pnpm install时，它会创建那个全局存储链接，并生成一个pnpm-lock.yaml文件来锁定依赖版本，类似于package-lock.json或yarn.lock。
有一点需要注意，由于 pnpm 创建的 node_modules 结构不同，有些极端老旧或写法不规范的包可能会找不到依赖。不过这种情况现在越来越少了，社区的兼容性已经做得很好。
一些实践中的体会
在实际项目中，尤其是 Monorepo 项目中，pnpm 的优势会成倍放大。它原生支持 workspace 协议，管理多个相互关联的包非常方便。在pnpm-workspace.yaml文件里定义好子包的目录，就能在根目录一键安装所有依赖，并且能很好地处理内部包之间的链接。
对于全局存储的位置，默认在用户目录下，通常不需要改动。但如果你的磁盘空间紧张，或者想统一管理，可以通过pnpm config set store-dir命令来修改路径。在 Docker 镜像构建等场景下，将全局存储挂载为卷，可以充分利用缓存，大幅加速镜像构建过程。
另一个小技巧是，pnpm的命令通常比 npm 更严格一些。比如默认情况下，pnpm add不会像npm install那样自动修改package.json，除非你明确使用-S或-D参数。这种设计促使开发者更明确地声明依赖的类型，算是一种良好的约束。
和 npm、yarn 放在一起看
现在主流的包管理器就这三个：npm, yarn 和 pnpm。npm 是官方出品，随着 Node.js 一起安装，生态最成熟，但过去在性能和磁盘空间上被诟病较多，不过最近的版本也在持续改进。
yarn 的出现最初是为了解决 npm v4 及之前版本的稳定性与速度问题，它引入了 lockfile 和并行安装，在当时是巨大的进步。yarn 2 及之后的版本（Berry）架构变化很大，采用了 Plug’n’Play 等激进方案，试图消除 node_modules，但带来了一些新的兼容性挑战。
pnpm 则走了另一条路：它没有试图消灭 node_modules 这个“约定”，而是通过链接的方式重构了其内部结构。这让它在获得性能与空间优势的同时，保持了极高的兼容性。它的哲学更像是“渐进式改良”，而非“革命”。对于大多数从 npm 或 yarn 1 迁移过来的项目和团队，pnpm 的迁移路径是最平滑、阻力最小的。你几乎不需要改变现有的工程脚本或部署流程。
选择哪一个，往往不是单纯的技术比较。如果团队已经深度使用 yarn 2 的特性，或者项目结构极其复杂，可能需要仔细评估。但对于绝大多数新项目，或者对磁盘空间、安装速度有要求的现有项目，pnpm 是一个非常稳妥且能带来即时收益的选择。它的设计，尤其是在处理 Monorepo 和保证依赖严格性方面，显得相当优雅和务实。
工具终究是工具，没有绝对的好坏。但 pnpm 这种基于链接的设计，确实为 Node.js 的依赖管理提供了一种久违的、简洁高效的思路。下次启动新项目时，不妨给它一个机会，亲自感受一下那种快速安装和整洁的 node_modules 带来的舒畅感。