仓库布局影响什么
单仓（Monorepo）把所有模块放在一个版本库里，跨模块改动可以一次提交、一次联合验证；多仓（Polyrepo）让每个模块独立版本化与发布，权限划分更细。选择取决于三件事：跨模块改动有多频繁、构建系统能不能只跑受影响的部分、团队规模是否已经需要独立的发布节奏。仓库布局不是技术洁癖问题，它直接决定依赖协调成本落在哪里。
基本信息
| 单仓前提 | 受影响分析与远程缓存能力到位，否则 CI 会退化成全量构建 |
|---|---|
| 多仓前提 | 包版本化规范与接口契约管理到位，否则依赖协调靠口头同步 |
| 成本转移 | 单仓把协调成本变成构建与权限治理；多仓把协调成本变成版本与依赖治理 |
| 迁移代价 | 仓库合并或拆分都会打断历史与流水线，属于长期投入 |
典型使用场景
- 多服务共享底层库：接口变更需要同步修改多个模块时，单仓能一次提交完成
- 前端多包项目：设计与组件库联调频繁，单仓可减少版本发布往返
- 不同团队独立交付：发布节奏差异大时，多仓减少相互阻塞
- 开源或外包协作：多仓便于按仓库授予权限并控制可见范围
- 合规隔离要求：不同等级代码需要独立访问控制时，多仓更容易落地
对比
| 维度 | 单仓（Monorepo） | 多仓（Polyrepo） |
|---|---|---|
| 原子提交 | 跨模块一次提交 | 需多次发布协调 |
| 构建 | 需受影响分析控制流水线时长 | 各自独立构建 |
| 权限 | 仓库级权限较粗，需目录级策略 | 按仓库授权更细 |
| 版本管理 | 统一版本，跨模块引用直接 | 需包版本化与依赖协调 |
| 发布节奏 | 统一流水线，影响面较大 | 独立发布，节奏灵活 |
单仓流水线要点
单仓流水线要点
1. 受影响分析：按改动文件推导需要构建与测试的模块
2. 远程缓存：命中未改动模块的构建产物，避免重复编译
3. 分阶段执行：先跑单元测试，再跑集成，失败早停
4. 提交门禁：跨模块改动必须跑覆盖各模块的联合测试
# 没有前两项，单仓的 CI 时长会随代码量线性增长使用要点
- 单仓不等于单构建：需要受影响分析与远程缓存才能控制 CI 时长
- 多仓要建立依赖升级流程：谁负责推动下游升级、多久必须升到某个版本
- 接口变更无论单仓多仓都要有契约与兼容性检查，仓库布局不能替代契约管理
- 明确回滚粒度：单仓回滚影响面大，多仓要处理版本兼容矩阵
单仓不等于单构建：需要受影响分析与远程缓存才能控制 CI 时长，工具与流程不到位时会拖慢流水线，反而比多仓更慢。
单仓下的权限是常见盲点：仓库级权限无法表达目录级隔离，涉及敏感配置或第三方代码时，需要额外的目录策略或拆分方案。