技能介绍

为什么需要它

当你管理多个 Node.js 项目时，常见的痛点是 node_modules 目录的磁盘冗余——同一个依赖包（比如 lodash）会被重复安装到不同项目的目录里，不仅占空间，还会拖慢安装和更新速度。另外，部分传统包管理器依赖扁平化的 node_modules 结构，容易出现幽灵依赖：明明项目没声明某个依赖，却因为其他依赖的深层依赖而能访问到，导致隐性故障。

它是怎么做到的

内容寻址存储与硬链接

pnpm 的核心是内容寻址存储（CAS）。它会把所有依赖文件存到一个全局的 pnpm-store 目录，每个文件的路径由其内容的哈希值决定（比如 store/v3/files/5a/12/34）。当项目安装依赖时，pnpm 不会复制文件到项目的 node_modules，而是创建指向 pnpm-store 的硬链接——多个项目共享同一个物理文件，自然大幅节省磁盘空间。比如更新 lodash 时，pnpm 只需把新版本的文件存入 pnpm-store，旧版本文件不会删除（因为可能有其他项目还在用），这就是资料里提到的“pnpm update 只会向存储中新增 1 个文件”。

严格的依赖隔离

pnpm 给每个项目生成独立的 node_modules，包之间的依赖不会“逃逸”到项目顶层。比如项目 A 依赖 react@18，项目 B 依赖 react@17，pnpm 会把它们分别安装到各自的 node_modules 里，避免版本冲突。

Monorepo 工作区支持

通过 pnpm-workspace.yaml 配置工作区，monorepo 里的多个子项目能共享 pnpm-store，同时保持各自的依赖边界清晰。比如一个 monorepo 里有 packages/ui 和 apps/web 两个子项目，它们可以共用 axios 的同一个版本，不会出现重复安装的情况。

适用边界与注意点

pnpm 本质是 Node.js 包管理器，需要配合 Node.js 运行时使用（可通过 pnpm config set node-version 管理 Node.js 版本）。另外，如果项目依赖某些必须扁平化安装的工具（比如 react-scripts 这类 CRA 工具），可能需要调整配置（比如 shamefully-hoist=true）来兼容。