【npm和pnpm的区别】深度解析与实用指南

在JavaScript和Node.js的开发生态中，包管理器扮演着至关重要的角色。它们负责下载、安装、管理项目所需的各种依赖。npm（Node Package Manager）作为Node.js的默认包管理器，长期以来占据主导地位。然而，随着项目规模的扩大和对效率、空间优化的需求增长，新的包管理器如pnpm应运而生，并迅速获得关注。

本文将围绕npm和pnpm的核心差异，从“是什么”、“为什么”、“如何”、“哪里”、“多少”等多个维度进行深入探讨，为您详细解读这两款工具的特点、优势、劣势及适用场景，帮助您做出明智的选择。

引言：核心差异概览

npm和pnpm最大的区别在于它们管理node_modules目录和存储依赖包的方式。npm通常采用扁平化（hoisting）或嵌套的结构，而pnpm则采用了一种基于内容可寻址存储（content-addressable store）的硬链接（hard links）和符号链接（symlinks）的独特方法。这种底层机制的不同，直接导致了它们在安装速度、磁盘空间占用、依赖管理严格性以及Monorepo支持等方面的显著差异。

是什么？—— 机制与结构的核心不同

理解npm和pnpm的关键在于理解它们是如何构建node_modules目录的。这个目录是Node.js项目存放所有依赖包的地方，其内部结构直接影响到项目的性能和稳定性。

npm的`node_modules`：扁平与嵌套的妥协

早期的npm版本（v2及以前）采用纯粹的嵌套结构，即每个依赖都会在其自己的node_modules目录中安装其子依赖。这种方式导致了路径过长、文件重复等问题。为了解决这些问题，npm v3及更高版本引入了“扁平化”（hoisting）策略。

扁平化 (Hoisting): npm会尝试将所有包及其子依赖尽可能地提升到项目根目录的node_modules下。如果多个包依赖同一个版本的子依赖，这个子依赖只会安装一次。
嵌套回退: 当存在不同版本但同名的子依赖时，npm会选择将其中一个版本提升到顶层，而另一个版本则保留在父依赖的node_modules中，形成嵌套结构。

扁平化带来的问题：

幽灵依赖 (Phantom Dependencies): 由于扁平化，项目可能会在不经意间使用到其直接依赖的子依赖（即未在package.json中声明的依赖），而这些依赖可能在未来某个版本中被移除或改变，导致项目代码在升级后突然报错。

不确定性: node_modules的最终结构可能因安装顺序或细微的版本差异而不同，这可能导致在不同环境中安装时出现“在我的机器上可以运行”的问题。

磁盘占用: 尽管有扁平化，但不同项目之间仍然无法共享同一个包的实例，每个项目都会有自己的一套node_modules，造成磁盘空间浪费。

pnpm的`node_modules`：革命性的硬链接与符号链接结构

pnpm的核心创新在于其对node_modules目录的构建方式。它不采用扁平化，而是创建了一个严格的、非扁平化的结构，同时通过硬链接和符号链接极大地优化了磁盘空间和安装速度。

内容可寻址存储 (Content-Addressable Store):
- 当您使用pnpm安装一个包时，该包的原始文件会被存储在一个全局的、内容可寻址的存储目录中（通常位于用户主目录下的.pnpm-store）。
- 这个存储目录是唯一的，无论您在多少个项目中安装同一个版本的包，该包的文件都只会在这一个地方存储一份。
- 包的路径是根据其内容（哈希值）决定的，确保了文件的唯一性和不变性。
硬链接 (Hard Links):
- 在每个项目的node_modules中，pnpm会创建对全局存储中实际包文件的“硬链接”。
- 硬链接不是文件的副本，而是指向文件在磁盘上同一物理位置的另一个入口。这意味着，虽然看起来项目node_modules中有一个完整的包，但它实际上并没有占用额外的磁盘空间，它只是引用了全局存储中的文件。
符号链接 (Symlinks):
- 项目的根node_modules目录中，不会直接包含所有的依赖。相反，它会包含指向一个隐藏目录.pnpm的符号链接。
- 在.pnpm目录下，每个包都有一个独立的目录，例如.pnpm/[email protected]/node_modules/react。这个目录是包的真实物理位置（通过硬链接指向全局存储）。
- 对于每个直接依赖，pnpm会在项目根node_modules中创建一个符号链接，指向其在.pnpm中的实际位置。
- 对于包的内部依赖（即包的子依赖），pnpm会为它们创建嵌套的符号链接，但这些符号链接只会链接到.pnpm目录中对应的兄弟包。这样，一个包只能访问其声明的直接依赖和间接依赖，而不能访问未声明的“幽灵依赖”。

pnpm严格性带来的优势：

这种结构确保了只有在package.json中明确声明的依赖才能被项目代码直接访问。如果代码尝试访问未声明的依赖，它将无法找到，从而避免了“幽灵依赖”问题，提升了项目的健壮性和可预测性。

为什么？—— 性能、空间与安全性的驱动

pnpm之所以能够脱颖而出，正是因为它有效地解决了npm在性能、磁盘空间占用和依赖管理严格性方面存在的问题。

为什么pnpm安装更快？

避免重复下载: 由于有内容可寻址存储，任何一个包的特定版本一旦被下载过，就会被全局缓存。后续在任何项目中再次需要这个包时，pnpm可以直接从本地存储中创建硬链接，无需再次从网络下载。这对于频繁进行pnpm install的场景（如CI/CD）或拥有大量项目的开发者来说，效率提升尤为显著。
硬链接创建速度快: 创建硬链接是一个文件系统操作，其速度远超复制文件。pnpm省去了大量的磁盘I/O操作，特别是对于大型项目或Monorepo，安装时间可以缩短数倍。
并行安装优化: pnpm在安装过程中能更好地并行化操作，进一步缩短了总安装时间。

为什么pnpm更节省磁盘空间？

全局唯一存储: 这是节省磁盘空间的核心原因。无论您有多少个项目，多少个node_modules目录，如果它们都依赖于同一个版本的同一个包，该包的物理文件在磁盘上只会存储一份。所有的项目都是通过硬链接指向这份唯一的物理文件。
消除冗余副本: 相比于npm的扁平化结构在处理不同版本子依赖时仍会产生重复副本，pnpm通过其严格的链接机制，最大限度地减少了冗余。
量化节约: 根据实际测试，pnpm通常可以比npm或Yarn节省50%到80%甚至更多的磁盘空间，特别是当您的机器上运行着多个Node.js项目时。

为什么pnpm更安全（防“幽灵依赖”）？

严格的依赖访问: pnpm的非扁平化node_modules结构强制代码只能访问其在package.json中声明的直接依赖。任何未声明的依赖，即使它们是某个直接依赖的子依赖，也不会暴露在顶层，因此无法被项目代码错误地引用。
杜绝版本冲突的隐患: 由于严格的符号链接结构，pnpm能够更好地隔离不同版本的同一个包，减少了由于版本冲突而导致运行时出现难以调试的问题。

为什么npm依然广泛使用？

历史遗产与默认地位: npm是Node.js的默认包管理器，拥有最长的历史和最广泛的用户群体。许多开发者习惯了它的工作方式。
生态兼容性: 虽然pnpm的兼容性已经很高，但偶尔仍有少量老旧工具或构建流程可能对非扁平的node_modules结构不够友好（尽管这种情况越来越少见）。
学习曲线: 对于新接触Node.js的开发者来说，npm的扁平化模型可能更容易理解，而pnpm的硬链接和符号链接概念略显复杂。
小项目优势不明显: 对于只有一个或几个小型项目的开发者来说，pnpm在性能和空间上的巨大优势可能不那么明显，npm的便利性足以满足需求。

如何？—— 安装、使用与迁移指南

从npm切换到pnpm并不复杂，pnpm的命令行接口与npm保持了高度的一致性，使得开发者可以平滑过渡。

如何安装pnpm？

使用npm全局安装 (推荐):
```
npm install -g pnpm
```
这是最常见且推荐的安装方式。
使用Corepack (Node.js v14.19+, v16.17+, v18+):
Corepack是Node.js内置的一个实验性工具，用于管理包管理器版本。您可以通过它启用pnpm。
```
corepack enable
```
然后在项目根目录的package.json中指定pnpm作为包管理器：
```
{
  "name": "my-project",
  "version": "1.0.0",
  "packageManager": "[email protected]" // 指定pnpm版本
}
```
之后，直接运行npm install等命令，Corepack会自动使用pnpm来执行。
通过脚本安装 (适用于无Node.js环境):
在某些没有预装Node.js的环境中，也可以通过pnpm官方提供的脚本安装。
```
curl -fsSL https://get.pnpm.io/install.sh | sh -
```
或
```
wget -qO- https://get.pnpm.io/install.sh | sh -
```

如何使用pnpm进行日常操作？

pnpm的命令与npm非常相似，大部分情况下您只需将npm替换为pnpm即可。

安装所有依赖:
```
pnpm install
```
或简写：
```
pnpm i
```

添加依赖:

pnpm add <package-name>

添加开发依赖：

pnpm add <package-name> --save-dev

或简写：

pnpm add <package-name> -D

添加可选依赖：

pnpm add <package-name> --save-optional

或简写：

pnpm add <package-name> -O

添加为peer依赖：

pnpm add <package-name> --save-peer

或简写：

pnpm add <package-name> -P

移除依赖:

pnpm remove <package-name>

或简写：

pnpm rm <package-name>

运行脚本:
```
pnpm run <script-name>
```
对于常用脚本（如start, test），可以直接运行：
```
pnpm start
```
更新依赖:
```
pnpm update
```
更新特定依赖：
```
pnpm update <package-name>
```
链接本地包 (monorepo或本地开发):
在要被链接的包目录下：
```
pnpm link --global
```
在要使用链接包的项目目录下：
```
pnpm link --global <package-name>
```
清理缓存:
```
pnpm store prune
```
删除所有缓存：
```
pnpm store status
```

如何从npm（或Yarn）迁移到pnpm？

迁移过程通常非常顺利：

确保已安装pnpm: 参照上述安装指南。
导入现有package-lock.json或yarn.lock:
pnpm可以识别并基于现有的锁文件生成自己的pnpm-lock.yaml文件。这有助于保持依赖版本的稳定性。
```
pnpm import
```
此命令会将npm或Yarn的锁文件转换为pnpm-lock.yaml。
删除旧的node_modules目录:
```
rm -rf node_modules
```
执行pnpm安装:
```
pnpm install
```
pnpm会根据新生成的pnpm-lock.yaml（或如果未执行pnpm import则根据package.json）安装依赖。
更新CI/CD配置: 将npm install或yarn install替换为pnpm install。

小贴士： 建议在迁移后运行一次项目的测试，确保所有依赖都正确加载和运行，特别是对于依赖了某些内部文件路径的复杂项目。

如何在CI/CD环境中使用pnpm？

pnpm在CI/CD环境中表现出色，因为它能极大地缩短构建时间。

安装pnpm: 在CI/CD脚本的开始阶段添加安装pnpm的命令。
```
npm install -g pnpm
```
或使用Node.js的Corepack功能。

缓存pnpm store: 为了最大化pnpm的优势，应该缓存pnpm的全局存储目录（~/.pnpm-store）。大多数CI/CD平台都支持缓存路径。

# 示例：GitHub Actions 缓存配置
- name: Setup pnpm
  uses: pnpm/action-setup@v2
  with:
    version: 8
    run_install: false # 不在此步骤安装依赖

- name: Get pnpm store directory
  shell: bash
  run: echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_ENV

- uses: actions/cache@v3
  name: Setup pnpm cache
  with:
    path: ${{ env.STORE_PATH }}
    key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
    restore-keys: |
      ${{ runner.os }}-pnpm-store-

- name: Install dependencies
  run: pnpm install --no-frozen-lockfile # CI/CD中通常使用frozen-lockfile，但这里为了示例通用性

执行pnpm install:
```
pnpm install --frozen-lockfile
```
在CI/CD中，通常建议使用--frozen-lockfile选项，它会检查pnpm-lock.yaml是否与package.json同步，如果不同步则会报错，确保构建的确定性。

如何在Monorepo项目中使用pnpm？

pnpm对Monorepo的支持非常优秀，甚至可以说是目前所有包管理器中最好的。它内置了对工作区（Workspaces）的支持，能高效地管理多个子包。

配置pnpm-workspace.yaml: 在Monorepo的根目录下创建此文件，指定工作区中的包路径。
```
# pnpm-workspace.yaml
packages:
  - 'packages/*'
  - 'apps/*'
  - 'shared/*'
```
安装所有工作区依赖:
在Monorepo根目录下运行：
```
pnpm install
```
pnpm会智能地安装所有子包的依赖，并自动处理子包之间的交叉依赖，通过符号链接建立关联，无需手动pnpm link。

运行特定子包的脚本:

pnpm --filter <package-name> run <script-name>

例如：

pnpm --filter webapp run start

运行所有子包的脚本:
```
pnpm -r run build
```
这会在所有工作区包中执行build脚本。

Monorepo优势： pnpm的硬链接和符号链接机制在Monorepo中发挥到极致。所有子包共享同一个全局存储，极大地节省了磁盘空间。同时，其严格的依赖管理确保了跨包依赖的正确性和隔离性，减少了潜在的冲突。

哪里？—— 最佳实践与适用场景

了解pnpm的机制后，我们来看看它在哪些场景下能发挥最大优势，以及它将内容可寻址存储放在何处。

哪些场景pnpm表现更优？

Monorepo项目: 这是pnpm最强大的应用场景之一。它能够高效管理多个相互关联的子项目，大幅提升安装和构建速度，并节省大量磁盘空间。
CI/CD环境: 由于其高效的缓存机制和快速的安装速度，pnpm可以显著缩短CI/CD流水线的执行时间，提高开发迭代效率。
磁盘空间有限的开发环境: 如果您的开发机器存储空间紧张，或者您同时管理着大量Node.js项目，pnpm能够为您节约大量宝贵的磁盘空间。
对依赖严格性有高要求的项目: 如果您希望避免“幽灵依赖”问题，确保项目代码只使用明确声明的依赖，pnpm是理想选择。
大型且依赖复杂的项目: 在这些项目中，npm的扁平化可能会导致更频繁的重复安装和潜在的依赖问题，pnpm能提供更稳定的环境。

哪些场景npm可能依然是默认选择？

初学者入门项目: 对于刚接触Node.js和JavaScript生态的开发者，npm作为默认工具，其概念相对简单，门槛较低。
极小型或一次性脚本项目: 对于那些只有一两个简单依赖的、快速原型或一次性脚本，pnpm的优势并不明显，npm的即用即走特性可能更方便。
团队已深度绑定npm生态且不愿迁移: 如果一个成熟的开发团队已经习惯并深度依赖npm的特定行为或生态工具，并且没有强烈的性能或空间优化需求，那么迁移成本可能高于潜在收益。

内容可寻址存储位于何处？

pnpm的全局内容可寻址存储目录通常位于用户的主目录下。

macOS/Linux: ~/.pnpm-store/v3 (~代表用户主目录，如/Users/your_username)
Windows: %LOCALAPPDATA%\pnpm-store\v3 (通常是C:\Users\your_username\AppData\Local\pnpm-store\v3)

这个目录是pnpm所有魔法的起点，它存储着所有被安装过的包的唯一物理文件。您可以通过运行pnpm store path命令来获取您系统上的确切存储路径。

多少？—— 性能与空间效益量化

量化pnpm带来的效益，能更直观地展现其价值。

能节省多少磁盘空间？

磁盘空间节约是pnpm最直观的优势之一。

量化节约比例:
在典型的开发环境中，如果您的机器上运行着多个Node.js项目，或者您正在处理一个包含多个子包的Monorepo，pnpm通常可以比npm或Yarn节省50%到80%甚至更多的磁盘空间。
实际例子:
假设您有10个项目，每个项目都依赖React、Vue、Lodash等常见库。如果使用npm，每个项目都会在自己的node_modules中拥有这些库的完整副本（或部分副本因扁平化而提升）。这意味着React在磁盘上可能存在10份。而使用pnpm，无论这10个项目是否都依赖React，React的物理文件在~/.pnpm-store中都只存储一份。所有项目都通过硬链接共享这个唯一的副本。这种重复消除机制在大规模依赖和多项目环境下尤为明显。一个Node.js项目即便在没有安装任何依赖时，node_modules的初始结构也可能占用几十甚至几百MB，而pnpm能将多个项目的这部分开销几乎“摊薄”为一份。

能提升多少安装速度？

安装速度的提升因项目大小、网络状况和缓存状态而异，但通常也相当可观。

全新安装 (无缓存):
在首次安装一个项目（或无缓存）时，pnpm的安装速度通常比npm或Yarn快1.5倍到3倍。这得益于其高效的并行下载和硬链接创建机制，减少了不必要的解压和复制操作。
增量安装 (部分缓存):
当您在现有项目上添加或更新少量依赖时，pnpm的优势更加明显。它只会处理新增或变更的包，并利用本地缓存。这种情况下，速度提升可以达到数倍甚至数十倍，因为大部分操作都变成了本地的硬链接和符号链接创建。
CI/CD环境 (利用缓存):
在配置了pnpm store缓存的CI/CD流水线中，后续构建的安装时间可以从几分钟缩短到几十秒甚至几秒。这对于频繁提交和部署的团队来说，是巨大的效率提升。

学习成本与生态兼容性“多少”？

学习成本:
对于日常使用，pnpm的命令集与npm高度相似，学习成本极低。您只需将npm替换为pnpm即可。然而，如果您需要深入理解其内部机制（如node_modules的结构、硬链接和符号链接的工作原理），那么会需要投入一定的学习时间。对于Monorepo的复杂配置和高级功能，也需要更多的时间去熟悉pnpm-workspace.yaml和相关的CLI命令。
生态兼容性:
目前，pnpm的生态兼容性已经非常成熟，绝大多数Node.js工具和框架（如Webpack, Vite, Next.js, React, Vue等）都能与pnpm完美协作。偶尔可能会遇到一些遗留工具或特定构建脚本，它们可能对扁平化的node_modules结构有强依赖，但这种情况越来越少。通常，这类问题可以通过调整工具配置或使用pnpm的shamefully-hoist选项（不推荐，但作为兼容性兜底）来解决。总体而言，兼容性问题非常少见且可解决。

其他疑问：兼容性、安全性与发展

兼容性问题如何？

pnpm在设计时就考虑了与npm生态的兼容性，大部分情况下可以无缝切换。如前所述，它尽量保持了与npm相同的命令行接口。然而，由于其独特的node_modules结构，偶尔可能在以下场景遇到兼容性问题：

依赖”幽灵依赖”的旧代码或工具: 如果您的项目或某些依赖明确依赖了未声明的间接依赖（即幽灵依赖），pnpm的严格模式会导致这些依赖无法被解析，从而引发错误。这通常是代码本身设计上的问题，pnpm反而会帮助您发现并修复这些不规范的依赖。
假设node_modules完全扁平的工具: 极少数旧工具或自定义脚本可能硬编码了对扁平化node_modules结构的路径假设。这类问题通常可以通过调整工具配置或升级工具版本来解决。pnpm提供了.npmrc配置中的shamefully-hoist=true选项作为临时的兼容性解决方案，但通常不建议长期使用，因为它会削弱pnpm的严格性优势。

安全性考量？

pnpm在安全性方面有显著提升：

避免幽灵依赖: 如前所述，pnpm的严格性防止了代码意外地使用未声明的依赖，这本身就是一种安全增强。它减少了因上游依赖变更而导致项目运行时崩溃的风险。
内容可寻址存储的完整性: pnpm通过哈希值来管理包，确保了存储中包文件的完整性。如果文件在传输或存储过程中被篡改，哈希值将不匹配，pnpm会拒绝使用。
包注册表的依赖: pnpm本身不直接提供新的安全扫描或漏洞检测功能，它依然依赖于npm Registry的安全性、您所使用的私有包注册表以及像Snyk、npm audit等工具来检测已知漏洞。

未来发展趋势？

pnpm作为一款现代化的包管理器，其发展趋势非常积极：

持续增长的采用率: 越来越多的项目和团队正在转向pnpm，尤其是在Monorepo和大型企业项目中。社区活跃度高，新功能和性能优化不断推出。
生态系统集成: 更多前端工具、框架和CI/CD平台正在加强对pnpm的官方支持。Node.js内置Corepack机制也进一步推动了pnpm的普及。
性能和效率的极致追求: pnpm团队将继续优化其核心算法，探索更高效的包管理方式，以满足日益增长的性能需求。
标准化: 随着时间的推移，pnpm的一些最佳实践和底层思想可能会影响未来包管理器或Node.js自身的标准。

总结

npm和pnpm都是优秀的JavaScript包管理器，但它们在设计哲学和底层实现上存在显著差异。npm作为默认选项，具有广泛的兼容性和较低的入门门槛；而pnpm则以其独特的硬链接和符号链接机制，在性能、磁盘空间占用和依赖严格性方面表现出压倒性优势，尤其适合大型项目、Monorepo和对CI/CD效率有高要求的场景。

选择哪个工具，最终取决于您的项目需求、团队偏好和对效率优化的重视程度。如果您追求极致的性能、高效的磁盘空间利用和更严格的依赖管理，pnpm无疑是更现代、更强大的选择。如果您只是处理小型项目或处于学习阶段，npm依然是可靠的伙伴。但无论选择哪个，理解其背后的工作原理，都将有助于您更好地管理项目依赖，构建健壮高效的应用程序。

npm和pnpm的区别

npm和pnpm的区别拓展一些是什么、为什么、哪里、多少、如何、怎么等通用的相关疑问问题

【npm和pnpm的区别】深度解析与实用指南

引言：核心差异概览

是什么？—— 机制与结构的核心不同

npm的node_modules：扁平与嵌套的妥协

pnpm的node_modules：革命性的硬链接与符号链接结构

为什么？—— 性能、空间与安全性的驱动

为什么pnpm安装更快？

为什么pnpm更节省磁盘空间？

为什么pnpm更安全（防“幽灵依赖”）？

为什么npm依然广泛使用？

如何？—— 安装、使用与迁移指南

如何安装pnpm？

如何使用pnpm进行日常操作？

如何从npm（或Yarn）迁移到pnpm？

如何在CI/CD环境中使用pnpm？

如何在Monorepo项目中使用pnpm？

哪里？—— 最佳实践与适用场景

哪些场景pnpm表现更优？

哪些场景npm可能依然是默认选择？

内容可寻址存储位于何处？

多少？—— 性能与空间效益量化

能节省多少磁盘空间？

能提升多少安装速度？

学习成本与生态兼容性“多少”？

其他疑问：兼容性、安全性与发展

兼容性问题如何？

安全性考量？

未来发展趋势？

npm的`node_modules`：扁平与嵌套的妥协

pnpm的`node_modules`：革命性的硬链接与符号链接结构