pnpm与Yarn对比分析

NPM、pnpm、Yarn 是 Node.js 生态三大包管理器，理解各自架构差异才能正确选型。

pnpm依赖管理对比

内容寻址存储模型

pnpm 使用全局内容寻址存储，所有包只存储一份：

~/.local/share/pnpm/store/v3/
├── files/           # 按 hash 存储包内容
│   ├── 00/          # hash 前两位分目录
│   ├── 01/
│   └── ...
└── metadata/        # 包元数据索引

# 查看存储路径
pnpm store path

# 分析存储空间
pnpm store status

# 清理未引用内容
pnpm store prune

pnpm 的 node_modules 通过硬链接指向全局 store，相同包仅占一份磁盘空间。

严格依赖隔离

node_modules/
├── .pnpm/                    # 真实包存放（硬链接到 store）
│   ├── lodash@4.17.21/
│   │   └── node_modules/
│   │       └── lodash/       # 硬链接
│   └── express@4.18.2/
│       └── node_modules/
│           ├── express/       # 硬链接
│           └── lodash/ -> ../../lodash@4.17.21/node_modules/lodash
├── lodash -> .pnpm/lodash@4.17.21/node_modules/lodash
└── express -> .pnpm/express@4.18.2/node_modules/express

• 无法访问未声明的依赖（幽灵依赖问题彻底解决）
• .pnpm 目录结构使每个包只能访问自身 dependencies 中声明的包

NPM/Yarn 的扁平 node_modules 允许访问未声明的依赖（幽灵依赖），pnpm 的嵌套结构杜绝此问题。

安装性能对比

# pnpm 安装命令
pnpm install              # 标准 install
pnpm install --frozen-lockfile  # CI 模式（等价 npm ci）

热启动时 pnpm 仅创建硬链接，无需下载，速度优势明显。

pnpm Monorepo 支持

# pnpm-workspace.yaml
packages:
  - 'packages/*'

# .npmrc
shamefully-hoist=true    # 兼容模式，类似 NPM 扁平结构
strict-peer-dependencies=true

shamefully-hoist=true 放弃严格隔离，回退到 NPM 的扁平模式，用于兼容老项目。

pnpm 局限性

• 严格模式可能导致依赖未声明的问题暴露，需修复 package.json
• 部分 NPM 生态工具假设扁平 node_modules，可能不兼容
• 原生模块（node-gyp）在硬链接场景偶有构建问题

Yarn包管理器对比

Yarn Classic（v1）vs Berry（v2+）

Plug'n'Play (PnP) 模式

# Berry 默认使用 PnP，不生成 node_modules
yarn install
# 生成 .pnp.cjs 和 .pnp.loader.mjs

// .pnp.cjs 内部结构（简化）
module.exports = {
  "packageLocations": [
    ["/path/to/.yarn/cache/lodash-npm-4.17.21.zip", "lodash", "4.17.21"]
  ],
  "packageDependencies": [
    ["lodash", "4.17.21"]
  ]
};

• PnP 通过 .pnp.cjs 映射表解析依赖，不依赖 node_modules
• 包以 zip 格式存储在 .yarn/cache/，解压开销为零

PnP 模式下 Node.js 需通过 .pnp.cjs hook 解析模块，部分原生模块和工具可能不兼容。

Yarn Berry 零安装

# 启用零安装
yarn config set enableGlobalCache false

# .gitignore 中排除缓存但保留 .pnp.cjs
.yarn/*
!.yarn/cache       # 提交缓存到仓库
!.yarn/patches
.pnp.*

• .yarn/cache/ 提交到仓库，clone 后无需 yarn install
• 适合小型项目或 CI 优化场景

零安装将缓存提交到 Git，仓库体积会持续增长，大型项目需评估可行性。

Yarn Workspace

// 根 package.json
{
  "private": true,
  "workspaces": {
    "packages": ["packages/*"],
    "nohoist": ["**/react-native"]
  }
}

# 工作区命令
yarn workspace @my/core add lodash
yarn workspaces run build
yarn workspaces foreach -t run build  # Berry 按拓扑执行

• nohoist 控制特定包不提升，解决 React Native 等工具的兼容问题
• Berry 的 foreach -t 按依赖拓扑排序执行，确保构建顺序正确

三者核心对比

选型建议：新项目优先 pnpm（效率+严格），兼容性要求高用 NPM，PnP 生态成熟度不足需谨慎。

要点总结

• pnpm 全局内容寻址存储 + 硬链接，相同包仅占一份磁盘，热启动极快
• pnpm 嵌套 .pnpm 结构杜绝幽灵依赖，但需修复历史项目的未声明依赖
• Yarn Berry PnP 模式取消 node_modules，依赖解析通过 .pnp.cjs 映射
• 零安装将缓存提交到仓库，适合小型项目，大型项目仓库体积会膨胀
• 新项目优先 pnpm，兼容性要求用 NPM，Yarn Berry 需评估 PnP 兼容性后选用