一句话定义：Monorepo（单仓库，也写作 mono-repo）是把多个项目、多个服务、多个库的代码放进同一个版本控制仓库里管理的做法，而不是每个项目单独开一个仓库。
打个比方：多仓库像一排独立的小屋，各家有各家的门锁和装修队；单仓库像一层开放式大办公室，所有人共享走廊、会议室和茶水间。找人走两步就到，公共的东西只有一份、不会各买一套；但门禁、卫生、装修必须统一规划，谁要动承重墙，得先跟整层楼打招呼。
它真正解决的问题：原子提交（atomic commit）。假设你改了公共组件库的一个函数签名，在同一次提交里就能把全部调用方一起改掉，CI 一次性验证通过。多仓库模式下，这件事要靠"先发库的新版本、再逐个升级各服务、中间还得忍受版本错配"来完成，任何一步漏掉都是线上事故。单仓库让"改一处、全链路一起验证"成为默认动作。
最容易混的两个邻居：
- Monolith（单体应用）说的是部署形态：一个程序打包上线。Monorepo 说的是代码组织形态，里面完全可以装几十个独立部署的微服务。一个是"怎么发"，一个是"怎么放"。
- Multi-repo / Polyrepo（多仓库）：每个项目一个仓库，仓库小、权限清晰，但跨项目改动要开一堆 PR、对齐版本号。
| 维度 | Monorepo | Multi-repo |
|---|---|---|
| 跨项目改动 | 一次提交搞定 | 多个 PR + 版本对齐 |
| 公共代码复用 | 直接引用，只有一份 | 发版后按版本引用 |
| 构建速度 | 需要增量构建与缓存 | 天然只构建自己 |
| 权限粒度 | 靠目录级规则和流程约束 | 仓库即边界，天然隔离 |
为什么 AI 智能体更偏爱它：智能体（agent）改代码靠的是检索到的上下文。单仓库里，调用方、被调用方、类型定义、测试用例都长在同一棵目录树下，一次搜索就能看到全链路，改完还能跑一次全仓校验；多仓库时它只看得见局部，很容易改出"这边编译通过、那边线上崩掉"的跨仓库破坏。上下文越完整，自动改代码的成功率越高——这是单仓库在 AI 时代被重新重视的直接原因。
代价也很实在：仓库体积大，代码检索和索引需要更聪明的过滤策略；构建慢，必须靠增量构建和远程缓存（remote cache）兜底；权限难细分，一个仓库里既躺着核心账务也躺着边缘脚本，只能靠目录级归属规则（如 CODEOWNERS）和纪律来补，工具链的具体支持以各项目官方文档为准。
对普通职场人的类比是：公司共享网盘还是每人一个 U 盘。共享的好处是版本唯一、不会出现"最终版-最终版2"，坏处是"谁动了我的文件"要靠制度回答。