还在为一个项目开十个仓库？还在为公共组件改个 bug 就要发布 N 个包而抓狂？

兄弟，你可能需要了解一下 Monorepo 了。当然，如果你觉得管理一个巨型仓库像是在维护一颗随时会爆炸的核弹，那么 MultiRepo 或许才是你的真爱。

核心差异

Monorepo（单体仓库）将所有关联代码聚合成一个仓库；MultiRepo（多仓库）则将各项目拆分至独立仓库。

一、核心区别：从存储到协作的全维度 PK

两者的差异贯穿代码存储、依赖管理、协作流程等全链路。废话不多说，先看对比表：

对比维度	Monorepo (基于 pnpm)	MultiRepo (传统模式)
代码存储	所有项目（Web、小程序、公共库）都在 1 个仓库，按目录划分。	每个项目独立成仓，仓库数量随项目线性增长。
依赖管理	硬链接机制，全局存储、全量共享。版本统一，没冗余。	各项目独立安装。容易出现“你用 v3，我用 v4”的版本碎片化。
跨项目修改	修改公共组件，子项目实时生效。一键构建，一次提交。	修改、测试、发布、更新、再测试。同步成本高到离谱。
版本发布	批量协调，关联功能同步发布。告别版本断层。	各发各的，全靠手动协调。容易出现“部分更新”的尴尬。
磁盘占用	极低（3 个项目约 80MB）。	极高（3 个项目约 450MB）。

1.1 依赖管理：谁更省空间？

Monorepo（基于 pnpm）流程：

graph LR
A[全局 Store] -->|硬链接| B[Monorepo 根目录]
B -->|引用| C[apps/web]
B -->|引用| D[apps/miniprogram]
B -->|引用| E[packages/ui]

MultiRepo 流程：

graph LR
A["Web 仓库"] -->|独立安装| B["lodash (1份)"]
C["小程序仓库"] -->|独立安装| D["lodash (第2份)"]
E["Admin 仓库"] -->|独立安装| F["lodash (第3份)"]

1.2 跨项目修改：谁更丝滑？

Monorepo 修改流程：

graph TD
A[修改公共 UI 组件] --> B[Web、小程序同步引用]
B --> C[pnpm filter 一键构建]
D[一次 Commit 搞定全家]

MultiRepo 修改流程：

graph TD
A["修改公共组件"] --> B["发布新 NPM 包"]
B --> C["去 Web 仓库更新依赖"]
C --> D["去小程序仓库更新依赖"]
D --> E["每个仓库各交一份 Commit"]

二、Monorepo（单体仓库）：真香还是真累？

2.1 为什么大家都说“真香”？

• 依赖共享的神器：基于 pnpm 的硬链接，3 个项目能省下近 80% 的磁盘空间。更重要的是，通过 pnpm-workspace.yaml 统一版本，再也不会遇到“本地好使，上线崩了”的版本兼容坑。
• 协作效率直接起飞：修改一个 packages/utils 里的函数，所有 apps 下的项目瞬间同步。以前要搞半天的跨项目联调，现在只要 1 分钟。
• 规范统一，新人救星：一套 ESLint、Prettier、Vite 配置全家桶。新人进来只需克隆一个仓库，半天就能上手，再也不用在十几个仓库之间反复横跳。
• 增量构建，拒绝摸鱼：配合 Turborepo，只构建改动过的部分。以前全量构建要 10 分钟，现在可能只要 3 分钟。

2.2 它的“坑”在哪？

• 仓库体积会“膨胀”：代码多了确实慢。不过 pnpm 支持稀疏检出，只拉你需要的目录，能缓解不少。
• 权限管理略显蛋疼：虽然可以通过 GitLab 的目录权限来搞，但配置起来确实比直接给仓库权限麻烦一点。
• 学习成本：得学会 pnpm workspace、filter、changesets 这一套工具链。初次搭建可能得掉两根头发。

三、MultiRepo（多仓库）：老牌选手的尊严

3.1 它的优点依然能打

• 轻量、纯粹：一个仓库就干一件事，简单直接。不需要什么复杂的 Workspace 配置。
• 权限隔离非常完美：A 团队看 A 仓库，B 团队看 B 仓库，互不干扰，安全感爆棚。
• 风险隔离：一个仓库的 CI/CD 挂了，不会影响其他项目的发布。

3.2 它的硬伤也挺疼

• 依赖冗余，版本地狱：随着项目变多，维护成本呈指数级增长。排查一个 lodash 版本不一致导致的 bug，可能会让你怀疑人生。
• 重复劳动：每个项目都要配置一遍规范，每个项目都要配置一遍 CI/CD。生命苦短，为什么要浪费在这些重复的事情上？

四、总结：我到底该怎么选？

别听那些大厂吹什么 Monorepo 才是未来，适合你的才是最好的。

建议选 Monorepo 的场景

1. 关联性极强：多个项目共享大量的公共组件、工具函数或类型定义。
2. 全栈开发：前端、后端、管理后台都在一套逻辑下。
3. 追求极致效率：团队厌倦了频繁的包发布和版本更新。

建议选 MultiRepo 的场景

1. 项目之间基本没关系：比如一个做商城，一个做官网，八竿子打不着。
2. 团队权限极其敏感：不同团队之间绝对不能互相看代码。
3. 快速原型开发：就是个临时的小活，没必要搞那套复杂的架构。