选包管理器时，表面是「谁更快」，底层其实是 Node 怎样解析模块、依赖怎样落到磁盘。这篇把几条主流路线串成一条脉络：各自解决什么、留下什么坑，以及和「模块解析」这条硬约束怎么博弈。读完你能快速对齐术语，并在新仓库里做出有理由的默认选择。

若你还关心锁文件、可复现安装在另一条语言里怎么落地，可与站内 2026 年 Python 包管理与依赖选择 对照；CI 里「装依赖再构建」的套路则与 GitHub Actions + Hexo 博客自动部署、全栈开发技术选型：Nuxt Nitro 与 Python 后端如何取舍 同属一类工程习惯。

读完你能带走：

  • Hoisting（依赖提升） 与 幻影依赖 为什么总是一起被提起。
  • pnpm 的内容寻址、node_modules/.pnpm 与「严格依赖」在行为上差在哪。
  • Yarn PnP 与 Bun 各自换掉的是哪一层，迁移成本大致有多高。

npm（2010–至今）：最早的「简单粗暴」设计带来的系统性问题

核心技术架构

  • node_modules 扁平结构 + Hoisting（依赖提升）：安装时，npm 会把依赖（含子依赖）尽量「提升」到根 node_modules，形成扁平树；行为细节以 npm 文档 与当前版本为准。
  • 每个项目独立拷贝：依赖包的实际文件复制到当前项目的 node_modules 里。
  • 依赖解析：Node.js 原生的 require.resolve 从当前文件向上逐层查找 node_modules。

由此产生的三大技术问题

  1. 幻影依赖（Phantom Dependencies）
    包 A 在 package.json 中声明了依赖 B，但项目代码里却能直接 import C（C 是 B 的子依赖）。
    原因：Hoisting 把 C 提升到根目录，解析时能找到，但 package.json 里未声明。
    后果：容易「在我机器上能跑」，换环境或上线后突然报错；供应链层面也多了一层不确定性。

  2. 磁盘占用
    同一版本（如 lodash@4.17.21）在不同项目里被完整拷贝多次；大型仓库里 node_modules 动辄数 GB。

  3. 安装速度与版本漂移

    • 早期无 package-lock.json（npm v5 起才有），仅靠 semver 实时解析时，同一 package.json 在不同机器可能装出不同树。
    • 老版本下载偏串行、缓存弱时，冷安装会偏慢。

npm 后续改进

v7+ 引入 workspaces、更强的缓存与锁文件实践，但底层仍是拷贝 + Hoisting 思路，上述结构性问题不会凭空消失。

Yarn 经典版 v1（2016）：针对 npm 痛点的「工程化补丁」

主要技术改进

  • yarn.lock：记录精确版本与依赖关系，安装结果更一致。
  • 并行下载 + 离线缓存：同时拉多个包，缓存到 ~/.yarn。
  • workspaces：较早支持 monorepo 多包同仓。

仍然存在的技术问题

  • 仍使用 传统 node_modules + Hoisting → 幻影依赖 未从机制上消除（主要是安装更快、锁更稳）。
  • 磁盘占用与 npm 同量级（仍全拷贝）。
  • Yarn v1 已进入 Legacy，新功能主要在 Yarn Berry 线。

pnpm（2017–至今）：用「内容寻址 + 硬链接」解决存储与一致性

革命性技术架构（pnpm 的核心创新）

  • 内容寻址存储（Content-Addressable Store）：全局 store（如 ~/.pnpm-store）按内容哈希存 tarball，多项目共用同一份物理文件。
  • 虚拟存储 + 硬链接/符号链接：项目 node_modules 里多为链接到全局 store；实际布局常见 node_modules/.pnpm，再通过链接约束「可见依赖」。
  • 更严格的依赖可见性：未在 package.json 声明的传递依赖，默认不会被挂到你能直接 import 的路径上（具体以当前 pnpm 版本与 node-linker 等配置为准）。

技术问题如何被缓解

  1. 幻影依赖大幅减少：只有声明过的依赖才会按规则出现在可解析路径上，行为更可预测。
  2. 磁盘占用更低：硬链接不重复占空间。
  3. 安装往往更快：大量工作变成建链接而非重复解压。

pnpm 引入的新问题（兼容性代价）

  • 目录结构与传统「满屏 node_modules」不完全一致，个别老工具、脚本假设了 npm 式布局时需要适配。
  • Windows 上符号链接 historically 有权限问题，近年工具链已改善，仍建议在目标环境自测。

Yarn Berry（Yarn 2+/4+，2020–至今）：「零 node_modules」的 PnP 架构

核心技术：Plug’n’Play (PnP)

  • 默认思路下不再依赖传统 node_modules 树。
  • 由 .pnp.cjs（及数据文件）维护 包 → 磁盘路径 的映射表；通过 Yarn 注入的解析逻辑配合 Node 加载模块。
  • 详见 Yarn PnP 官方说明。

技术优势

  • Zero-Installs 等流程下，仓库可携带缓存，协作时减少「先装十分钟」的摩擦（团队策略自定）。
  • 解析可走映射表，减少在文件系统里深搜 node_modules。
  • Constraints 等能力便于在 monorepo 里统一约束依赖版本。

引入的新问题

  • 工具链适配：部分工具默认假设物理 node_modules，需插件或 nodeLinker: node-modules 等回退策略。
  • 调试心智：路径与 module.paths 等与纯 npm 布局不同，排错前要接受一层映射。
  • 团队学习曲线与迁移成本明显高于「换用 pnpm」。

Bun（2022–2026）：全栈一体化 + 极致性能的新范式

技术底层

  • 以 Zig 实现运行时与包管理（不绑定在 Node 上）。
  • 包管理侧常见 全局缓存 + 内容寻址 思路，强调并发与 I/O。
  • All-in-One：包管理、runtime、bundler、test 等集成，减少多进程切换。

解决的问题

  • 冷安装在不少基准场景下显著快于传统 npm/Yarn v1。
  • 依赖解析与执行路径更短（同一套二进制内完成）。

当前技术局限

  • 与 Node 生态的兼容：依赖原生插件、特定 Node API 的包需要逐项验证。
  • 定位是运行时 + 工具链，不是「只换一个安装器」那么轻；生产落地前建议在非核心链路试跑。
  • 选型讨论可见 Bun 文档。

动手片段：三条命令对齐体验

下面假设本机已装 Node 20+，仅用于「感受差异」，不代表生产唯一写法。

片段 1：npm 与锁文件（可复现安装）

1
2
3
mkdir demo-npm && cd demo-npm && npm init -y
npm install lodash@4.17.21
npm ci   # 在已有 package-lock.json 的 CI/克隆场景用，避免随意改锁

片段 2：pnpm 与 store

1
2
3
mkdir demo-pnpm && cd demo-pnpm && pnpm init
pnpm add lodash@4.17.21
pnpm store path   # 查看全局 store 路径，理解「多项目共用物理文件」

片段 3：Yarn Berry（需已启用 corepack 或按官方安装 Yarn）

1
2
3
mkdir demo-yarn && cd demo-yarn && yarn init -2
yarn set version stable
# 按团队策略选择 PnP 或 node-modules；改 nodeLinker 后需重新 install

对比一览（2026）

技术维度 npm Yarn v1 pnpm Yarn Berry (PnP) Bun
存储方式 全拷贝 全拷贝 全局内容寻址 + 硬链接 缓存 + 映射表 全局内容寻址（更快）
幻影依赖 有 有 严格策略下显著缓解 机制上规避 依实现，多严格解析
node_modules 常见布局 常见布局 含 .pnpm 等布局 可无传统树 非 Node 传统模型
monorepo 效率 一般 好 极佳 极佳 好
团队迁移成本 0 低 中 高 高
适用场景 最大兼容 历史项目 多数新仓均衡之选 强约束、零安装团队 性能与新运行时试验

表格是归纳，以你团队锁定的主版本文档为准；「幻影依赖」一列在不同配置下会有灰度，上线前用真实依赖树测一轮最稳。

一句话：各种方案都在 Node（或兼容层）的模块解析规则 与 磁盘/网络/确定性 之间做取舍——没有「绝对最好」，只有「当前仓库最省总成本」。

核心要点

  • 根矛盾：扁平 Hoisting 换安装简单，却带来幻影依赖与体积问题；严格布局（pnpm / PnP）换可预测，却要付工具链适配成本。
  • npm / Yarn v1：心智简单、兼容广；若仍用，务必用好锁文件与 CI 上的 npm ci / 等价物，减少「同 lock 不同树」。
  • pnpm：在磁盘、速度与依赖可见性之间平衡较好，多数新前端仓我会优先评估（仍以团队现状为准）。
  • Yarn Berry（PnP）：适合愿意统一工具链、接受映射表心智的团队；否则可用 nodeLinker 回到类 node_modules 模式。
  • Bun：适合愿意绑定其 runtime 工具链、追求端到端速度的场景；与 Python 侧 uv 类似，都是「新运行时 + 新安装哲学」，跨栈对照可读 Python 依赖笔记。
  • 选型动作：新项目先定 锁文件策略 + CI 安装命令，再定包管理器；已有仓迁移时按「依赖数量、原生模块、Docker/IDE」列清单试点。