npm与pnpm：存储、速度及实际应用中的权衡对比
本文对比了npm与pnpm在依赖存储、安装速度以及单仓库项目工作流程方面的表现，帮助您为项目选择合适的工具。
如果你曾花时间使用 React、Next.js、Node.js 或其他现代 JavaScript 框架进行开发，那么你很可能已经无数次地输入过这条命令：
npm install
它简单有效，人人都认识它，几乎所有的在线教程都会用到它。
后来，总有人会对你说类似这样的话：
“你为什么还在用 npm？直接用 pnpm 不就行了吗？”
于是你开始尝试使用 pnpm。
不久之后，你就会开始思考：
pnpm 真的正是一种升级吗？还是说这只是又一场几个月后就会被人遗忘的 JavaScript 工具争论而已？
这确实是一个值得思考的问题。
npm 本身并没有任何问题。它使用起来熟悉、可靠，而且会随 Node.js 自动安装。只有当有充分的理由时，才需要考虑放弃它。
一旦深入了解每个工具的实际运作方式，你就会发现真正的焦点并非简单的npm与pnpm的对比。
关键在于它们管理依赖的方式、占用的磁盘空间大小、在不同条件下的安装行为，以及你所构建的项目类型。
而最重要的问题是：
哪一种工具更适合你使用？
npm与pnpm解决的是同一个核心问题
让我们从显而易见的事实开始。
npm和pnpm都是为Node.js环境设计的包管理器。
它们都从npm注册表获取包，并遵循相同的package.json规范。
假设你的项目需要React，你可以使用npm来安装它：
npm install react
或者也可以选择使用pnpm：
pnpm add react
无论哪种方式，最终都能成功安装React。
你并没有切换到完全不同的 JavaScript 生态系统。
真正发生变化的是，包被安装并存储在你的机器上之后的内部处理方式。
正是在这一点上，pnpm 的设计开始展现出优势。
它们真正的差异所在：依赖项的存储方式
想象一下你的电脑上存在五个独立的 JavaScript 项目。
它们每一个都依赖 React。
使用传统的 npm 设置时，每个项目都会维护自己的独立 node_modules 文件夹，用来存放其所需的包。
当这样的项目数量增多时，就会产生大量重复的文件，占用大量空间。
pnpm 采取了不同的方法。
它将所有包存储在同一个内容可寻址的存储系统中，然后从该系统为每个需要这些包的项目创建链接。
简单来说，pnpm 不会为每个项目重复创建相同的包，而是可以直接重用其中央存储中已有的副本。
可以这样理解：
Project A ──┐
Project B ──┤
Project C ──┼── Shared package store
Project D ──┤
Project E ──┘
实际上背后的机制比那幅简单的图示要复杂，但核心理念才是关键。
pnpm 的设计目的就是尽量减少冗余副本。
如果你同时处理多个项目，这种设计选择能显著降低磁盘使用量。
pnpm 真的能更快地安装软件吗？
这通常是开发者最先想了解的问题。
诚实的答案是：
大多数情况下可以——但并非总是如此。
许多测试结果表明 pnpm 在速度上远超 npm。
不过需要注意的是，安装速度取决于诸多变量。
你的网络连接状况也很重要。
硬盘硬件同样有影响。
项目所依赖的包的数量也很关键。
这些包是否已经缓存在本地也会产生差异。
项目的大小也是一个因素。
即使是全新安装与重新安装之前已下载过的内容，结果也可能大相径庭。
pnpm的架构以高效的下载和链接为核心，由于它拥有共享存储机制，本地已有的包可以直接复用，无需再次下载。
正是在这种情况下，它的优势才能真正显现出来。
冷安装与热安装的差异十分明显
这是人们在比较包管理器时常常忽略的一个细节。
假设你正在首次安装某个包。
你别无选择，只能从头下载它。
这本质上就是一种冷启动场景。
现在想象一下，完全相同的包已经存在于你机器上的另一个项目中。
那便是截然不同的起始点。
这正是 pnpm 的共享存储发挥作用的地方。
pnpm 不会将每个项目都视为完全孤立的单元，而是可以从已本地存储的包中获取资源。
因此，如果你经常创建新项目、删除 node_modules 文件夹、频繁重新安装依赖，或在不同仓库之间切换，随着时间推移 pnpm 的高效性会愈发明显。
但若你的工作流程只是处理一个简单的项目，并且只安装一次依赖，那么可能不会明显感受到其中的差异。
正因如此，我建议避免做出如下断言：
“pnpm 总是更快的选择。”
更准确的表述应该是：
pnpm 通常效率更高，尤其是在需要频繁安装或依赖关系较为复杂的工作流中。
npm 已经远远超越了其旧有的形象
这里还有另一点值得提及。
很多关于 npm 与 pnpm 的讨论都将 npm 描述为一种过时的工具，开发者早就应该弃用它了。
这种描述其实并不准确。
npm 已经取得了长足的进步。
当前版本支持工作区、锁定文件以及 npm ci 等功能，可在 CI 流水线中实现可重复的安装过程。
例如：
npm ci
当需要通过锁定文件实现干净的安装时，就会经常使用它。
因此，称 npm 运行缓慢、过时或设计糟糕是站不住脚的。
对于绝大多数项目而言，它依然是一个非常可靠的选择。
pnpm 的独特之处在于它做出了以效率为导向的特定设计决策，而随着项目规模的扩大，这些优势会愈发明显。
开发者常遇到的另一个区别：依赖隔离
这一点并不容易立刻察觉，尤其是对于刚接触该生态系统的人来说。
想象这样一种情况：你的应用依赖于包 A，而包 A 又依赖于包 B。你从未自行安装过 B，甚至也没有在项目清单中列出它。但由于 node_modules 的结构特点，你的代码仍可能直接 require 或 import B，而且能够正常运行。
有一段时间里，似乎并没有什么问题。
此时，包A会更新并替换其依赖项。包B不再处于代码预期的位置，于是你的应用程序突然抛出你未曾预料到的错误。
这种情况有个专门的名称：幻影依赖。你实际上依赖于本不应依赖的东西。
pnpm通过设计避免了这一问题。它的默认结构对包能够访问的内容有着更严格的要求，这使得项目很难依赖那些未被明确声明为依赖项的元素。
这确实是一项非常有价值的保障。它迫使你诚实地面对应用程序的实际需求，而非利用文件布局上的偶然优势。从长远来看，这种正确性往往比缩短几秒钟的安装时间更为重要。
pnpm真正大放异彩的场景：单仓库项目
这或许是选择 pnpm 的最有力理由。
想象一下这样一个公司代码库的结构：
my-project/
│
├── apps/
│ ├── web/
│ └── admin/
│
├── packages/
│ ├── ui/
│ ├── utils/
│ └── config/
│
└── package.json
其中有几个应用程序以及少量共享的内部包，全都存在于同一个仓库中。这种架构就是人们所说的单仓库项目。
npm 确实支持工作区功能，因此使用 npm 构建单仓库项目是完全可行的。但 pnpm 在单仓库工具方面投入了更多精力，它提供了诸如工作区协议、用于针对特定包运行命令的过滤标志，以及专为多包仓库设计的依赖模型——所有这些都能显著提升大型代码库的可管理性。
如果你只是在维护一个小型个人项目，这些功能其实并不重要。
但如果你维护的仓库中包含多个应用程序以及数十个内部共享包，那么这类工具就显得尤为重要。
从 npm 转换到 pnpm 并不复杂
开发者不愿尝试 pnpm 的一个常见原因是他们以为必须学习一整套新的命令。
其实并非如此。大多数日常使用的命令几乎都能实现一一对应。
使用 npm 安装依赖项的操作如下：
npm install
而使用 pnpm 则是：
pnpm install
在 npm 中添加包的操作：
npm install axios
在 pnpm 中则变为：
pnpm add axios
在 npm 中添加开发依赖项的操作：
npm install -D typescript
变为：
pnpm add -D typescript
在 npm 中卸载包的操作：
npm uninstall axios
变为：
pnpm remove axios
在 npm 中运行脚本的操作：
npm run dev
可以简化为：
pnpm dev
如果你已经熟悉 npx，pnpm 也有类似的工具：
pnpm dlx
因此这里的学习曲线其实非常平缓。
NPM 仍然最合适的场景
如果你正在首次向他人介绍 JavaScript 或 Node.js，NPM 是最自然的起点。这并非因为它在技术上处处更优——而只是因为它默认就已存在，初学者无需再为选择包管理器而增加学习负担。
如果教程要求你执行：
npm install express
你只需直接输入命令，然后继续学习所讲解的实际概念即可。
当你要进入一个已经基于 NPM 构建的代码库时，使用 NPM 也是正确选择。强行改变这一做法几乎没有意义：
“团队一直都在使用npm，但这里更倾向于使用pnpm，所以让我们把整个配置都转换过来吧。”
在团队环境中，保持与其他人使用的一致性比追求个人偏好更重要。
pnpm更值得使用的场景
随着项目或工作流的规模扩大，pnpm的优势会愈发明显。
如果你需要同时处理多个JavaScript项目，pnpm的共享内容寻址存储功能可以减少各项目之间的冗余磁盘占用。如果你的依赖树庞大且复杂，更快、更轻量的安装速度就会变得尤为重要。而如果你在管理单仓库项目，pnpm的工作区功能绝对值得认真考虑。
依赖隔离是选择它的另一个理由——如果项目中对已声明的依赖与实际可使用的依赖之间要有严格的界限，pnpm 默认就会强制执行这一规则。
简单来说：JavaScript 环境越复杂，pnpm 的优势就越明显。
那么，在速度方面谁更胜一筹？
若非要给出一个答案，pnpm 在安装效率上通常更具优势，尤其是当其共享存储已将相关包缓存到本地时。
不过，这样断言并不准确：
"pnpm 的速度恰好是 npm 的两倍。"
那种说法过于简化了问题。基准测试结果会因环境条件而大相径庭。通过快速网络连接进行全新安装，与在已缓存了大部分软件包的本地机器上重新安装是无法相提并论的。而且持续集成环境与本地机器的表现也有差异。
因此，如果仅仅因为基准测试图表就考虑更换包管理器，更好的做法是在做出决定之前先审视自己的工作流程。
我的选择
对于小型 React 项目，npm 已经足够好用，无需额外折腾。
学习型项目也是如此——npm 完全适用。
如果是要加入现有的团队代码库，就使用团队已经标准化的工具。
不过对于大型单仓库项目，ppnm 则是一个值得考虑的强劲竞争者。
如果你使用的机器上需要频繁在多个 JavaScript 项目之间切换，pnpm 通常是更实用的选择。
正因如此，这里并不存在一个绝对最优的解决方案。
不要仅仅因为 pnpm 正流行就更换
这可能是整个对比中最重要的一点。
仅仅因为 pnpm 经常出现在网上的开发者讨论中，你就没必要把所有现有项目从 npm 迁移到 pnpm。
当然，更不必因为有人坚称：
“npm 已经死了。”
就选择更换。事实并非如此。这两种工具都有人持续维护，背后都有成熟的生态系统，而且完全能够胜任现代 JavaScript 项目的需求。
真正的问题并非“哪种包管理器客观上最优秀”，而是“哪种包管理器更适合我的工作方式”。
如果你正在开发小型应用、学习某种编程语言，或者所在团队已经依赖 npm，那么继续使用 npm 是完全合理的选择。
而如果你需要处理大型项目、多个仓库或单仓库架构，并且希望实现更高效的依赖存储与更快速的安装速度，那么不妨试试 pnpm。
总结
在开始对比 npm 和 pnpm 之前，我原以为会有一个简单明确的结论——npm 是过时的选择，而 pnpm 则是更高效的升级方案。
但实际情况要复杂得多。
npm 的核心优势在于其简单性以及几乎所有人都已经熟悉它这一事实。它能成为默认选项自有其原因。
pnpm的核心优势在于其依赖存储模型、安装时的高效性，以及为大规模项目提供的工具支持。
因此，如果你是JavaScript新手，不必为此纠结——直接使用npm开始开发即可。
如果你已经熟练掌握Node.js且项目规模正在扩大，可以试试pnpm，看看它能否提升你的日常工作效率。
归根结底，决定应用程序优劣的并非你选择的包管理器。
真正起作用的还是你的代码。
相关阅读
- 适用于本地开发与生产服务器的Node.js命令参考——这份易于查阅的参考手册涵盖了Node.js版本管理、包管理器、环境配置、调试、PM2以及无中断Linux部署等内容。