Monorepo 工具链选型：pnpm 11 Workspace、Turborepo 2 与 Nx 23

代码仓库该拆还是该合？2026 年的工程实践已经给出偏向性答案：中大型前端/全栈项目，Monorepo 是主流选择。而工具链之争，主要落在 pnpm Workspace、Turborepo、Nx 三者之间。

本文基于当前版本（pnpm 11.24.0、Turborepo 2.10.12、Nx 23.1.2），讲清它们的分工边界与组合方式。

一、先厘清：它们不是一个层面的东西

这是最常见的误解——很多人以为三者是互斥选项，实际上它们解决的是不同层的问题：

• pnpm Workspace：解决依赖安装与包之间的软链接。它让多个包共享同一份依赖、本地包之间互相引用；
• Turborepo：解决任务编排与缓存。它负责决定”哪些任务要跑、能否复用上次结果、能否并行”；
• Nx：解决工程治理。它包含任务编排、依赖图分析、代码生成、受影响项目检测，还带分布式缓存与 IDE 集成。

因此最常见的组合是 pnpm Workspace（管依赖）+ Turborepo 或 Nx（管任务）。真正的二选一发生在后两者之间。

二、三者定位对比

三、pnpm Workspace：地基

# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'packages/*'
  - '!**/dist/**'

pnpm 的硬链接 + 内容寻址存储让多包项目的安装速度与磁盘占用远优于传统方案。实践建议：

• 用 catalog: 统一管理常用依赖版本，避免各包版本漂移；
• 用 pnpm --filter 精准对某个包执行命令；
• CI 里用 lockfile 冻结安装，开启 store 缓存提速。

四、Turborepo：够用就好的编排

// turbo.json（示意）
{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": { "dependsOn": ["build"], "outputs": [] },
    "lint": { "outputs": [] }
  }
}

核心概念只有两个：任务依赖拓扑（^build 表示先构建上游依赖包）与产物缓存。它的优势是配置简单、心智负担小，团队半天就能上手。

五、Nx：当规模上来了再考虑

Nx 的价值在大仓治理：依赖图可视化、受影响项目精确到文件、代码生成器统一脚手架、分布式任务执行。当你的仓库有几十个包、多个团队并行开发、CI 时间成为瓶颈时，Nx 的能力是对症的。

代价是配置与概念更多，团队需要投入学习成本。小团队硬上 Nx，往往会觉得”复杂但没用上”。

六、选型决策

3 人以内的项目、包数量 < 10：pnpm Workspace 即可，脚本够用别上编排工具。
中型项目、追求快速接入：pnpm + Turborepo，性价比最高。
大型多团队仓、CI 时长已成瓶颈：pnpm + Nx，用受影响检测与分布式缓存换时间。
已有 CI 编排能力：只上 pnpm Workspace，用现有流水线补任务缓存。

七、五个落地要点

1. 边界先划清。 按业务域而非技术层分包（packages/order 而不是 packages/utils 一锅炖）；
2. 依赖方向单向。 上层可以依赖下层，禁止反向依赖与循环依赖，用 lint 规则固化；
3. 缓存要正确声明产物。 outputs 写错会导致命中错误的缓存，产生诡异的构建结果；
4. CI 只跑受影响的项目。 这是 Monorepo 提速的最大杠杆；
5. 版本发布统一策略。 用 changeset 之类的方案管理版本号与 changelog，避免手工出错。

八、小结

Monorepo 工具链在 2026 年已经成熟，选择不再是”谁更强”，而是”你的规模和团队能吃下多少复杂度“。

默认建议：pnpm Workspace + Turborepo 起步，规模上来了再评估 Nx。工具是手段，仓库结构清晰、依赖方向可控，才是 Monorepo 成功的前提。

版本数据来源：npm registry（pnpm、turbo、nx 包页面）；采集于 2026 年 9 月 1 日。参考：pnpm Workspace 文档、Turborepo 文档、Nx 官方文档。