包管理器选型
前端工程化中，包管理器负责依赖安装、版本锁定与 Monorepo 协作。选型直接影响磁盘占用、安装速度、依赖隔离和 CI 耗时，是工程化基础设施里值得单独评估的一环。
Monorepo 优先 pnpm；小项目求稳用 npm；已有 yarn 2+ PnP 且无兼容问题可继续用 yarn候选方案概览
| 工具 | 定位 | Lock 文件 |
|---|---|---|
| npm | Node 默认包管理器，v3+ 采用扁平化 node_modules | package-lock.json |
| yarn | 引入缓存与确定性安装；v2+ 可选 Plug'n'Play（PnP） | yarn.lock |
| pnpm | 内容寻址 + 硬链接/符号链接，严格依赖隔离 | pnpm-lock.yaml |
选型对比
| 维度 | npm | yarn | pnpm |
|---|---|---|---|
| 依赖结构 | 扁平化 node_modules | 扁平化；v2+ 可选 PnP（无 node_modules） | 符号链接构建非扁平虚拟树 |
| 幽灵依赖 | 存在（可引用未声明的包） | 存在 | 不存在，严格隔离 |
| 磁盘占用 | 每个项目独立拷贝 | 每个项目独立拷贝 | 全局内容寻址 + 硬链接，复用同一版本 |
| 安装速度 | 较慢（早期无并行） | 快（并行 + 缓存） | 快（并行 + 全局硬链接复用） |
| Monorepo | workspaces | workspaces | 原生 pnpm workspace，空间与速度优势明显 |
| 安全性与隔离 | 一般 | 较好（checksum 校验） | 最佳（非扁平结构限制非法访问） |
核心机制差异
依赖结构：扁平化 vs 符号链接
npm / yarn 扁平化
早期 npm 采用嵌套 node_modules，在 Windows 上易出现路径过长，且同一包多版本会重复安装。扁平化将所有依赖提升到顶层 node_modules，缓解了嵌套问题，但带来两个副作用：
- 项目代码可以引用未在
package.json中声明的传递依赖（幽灵依赖） - 多版本冲突时只能保留一个版本，其余被迫嵌套
pnpm 符号链接方案
- 项目
node_modules顶层只有直接依赖的符号链接，指向node_modules/.pnpm虚拟存储 .pnpm内通过硬链接指向全局内容寻址仓库
依赖关系与 package.json 声明一致，无法访问未声明的包；相同版本全局只存一份。
磁盘空间与安装性能
| 方式 | 行为 | 典型影响 |
|---|---|---|
| npm / yarn | 每个项目独立复制依赖 | 10 个项目用同一依赖，磁盘占 10 份 |
| pnpm | 全局单一仓库（~/.pnpm-store）按内容哈希存储，项目通过硬链接引用 | 大型 Monorepo 可节省 70%–90% 磁盘；安装速度常快 2–3 倍 |
安装新版本时，pnpm 只增量存储变化部分；删除项目仅移除链接，不影响全局仓库。
yarn Plug'n'Play（PnP）
yarn 2+ 可选 PnP 模式：完全抛弃 node_modules，改用 .pnp.cjs 映射依赖位置。
| 优点 | 缺点 |
|---|---|
| 安装极快（无需写大量文件） | 部分 Webpack 插件、ESLint 配置等不兼容 |
| 启动快 | 社区普及度低，团队学习成本较高 |
场景选型建议
| 场景 | 推荐 | 原因 |
|---|---|---|
| 个人/小项目，求稳、零额外工具 | npm | 随 Node 自带，生态绑定最好 |
| 需要更快安装与版本确定性（存量 yarn v1 项目） | yarn v1 | 成熟稳定；相对 npm 的优势已缩小 |
| 大型 Monorepo | pnpm | 磁盘节省明显，依赖隔离严格，CI 安装更快 |
| 追求严格依赖管理与安装性能 | pnpm | 现代前端工程的主流选择 |
| 已用 yarn 2+ PnP 且无工具链兼容问题 | yarn (PnP) | 启动性能最佳，需团队熟悉 PnP 机制 |
常见顾虑
幽灵依赖与线上风险
扁平化结构下，开发环境能 import 到未声明的包，上线后若该传递依赖版本变化或被移除，可能触发运行时错误。pnpm 在开发阶段即暴露此类问题，有利于提前修复。
迁移成本
从 npm/yarn 迁移到 pnpm 通常需要：
- 删除旧 lock 文件与
node_modules，重新pnpm install - 检查 CI 脚本中的
npm install/yarn命令 - 排查依赖未声明但代码中引用的包（pnpm 会报错，需补全
package.json） - 部分工具需配置
.npmrc（如shamefully-hoist仅作临时兼容，不建议长期使用）
生态兼容
pnpm 对 npm 生态兼容性已很好；少数老旧工具假设扁平 node_modules 布局，可能需额外配置。yarn PnP 的兼容面更窄，选型时需实测构建链。
依赖目录结构示意
npm / yarn node_modules:
├── A (v1.0)
├── B (v1.0)
│ └── node_modules/C (v2.0) # 版本冲突时才嵌套
└── D (v1.0)
pnpm node_modules:
├── A -> .pnpm/A@1.0/node_modules/A
├── B -> .pnpm/B@1.0/node_modules/B
├── D -> .pnpm/D@1.0/node_modules/D
└── .pnpm/
├── A@1.0/node_modules/ (包含 A 及依赖)
├── B@1.0/node_modules/ (包含 B 及依赖 C)
└── C@2.0/ (硬链接至全局 store)
总结
- npm：默认、稳妥，适合小项目或对工具链零配置要求的场景。
- yarn v1：存量项目可继续维护；新项目若无历史包袱，优势相对 pnpm 不明显。
- pnpm：Monorepo、多仓库并行开发、CI 磁盘与耗时敏感的场景首选；严格依赖隔离有助于减少幽灵依赖导致的线上问题。
- yarn PnP：工具链完全兼容时的性能选项，但兼容与运维成本需单独评估。
本仓库前端工程化方案统一采用 pnpm（见 前端工程化），兼顾 Monorepo 空间效率、安装速度与依赖隔离。