一个仓库，多个项目
Monorepo 把应用与共享库放在一起。价值不在同一目录本身，而在于它带来的工作流：修改共享库和所有使用方可以在一个提交中完成，一起评审、互相测试。现代工具会构建依赖图，只为受影响的项目执行任务，并在多台机器和 CI 运行之间共享缓存。
repo/
apps/web/
apps/api/
packages/ui/
packages/config/
pnpm -r --filter "...[origin/main]" test何时使用
当项目共享代码且经常一起变更、依赖版本需要对齐、或者希望统一 CI 配置与评审文化时，选择 monorepo。若团队完全独立、仓库体积会拖慢克隆、或者必须按项目严格隔离权限，则应避免。与多仓库相比，monorepo 简化原子变更，但集中了工具复杂度。
权衡
若没有受影响项目执行与缓存，克隆和 CI 会越来越慢。所有权边界需要 CODEOWNERS 之类的显式规则。工具锁定是真实成本：从某个 monorepo 工具迁走代价很高。权限控制也更粗，仓库权限会覆盖内部所有项目。
示例与常见误解
某团队修改 packages/ui 中的按钮组件。受影响图会重建该组件，再重建 apps/web，并跳过 API 与文档项目，一个 Pull Request 就带着所有使用方的测试一起发布。认为 monorepo 等于单一部署的误解，把仓库布局与发布拓扑混为一谈。相关概念包括构建缓存、依赖固定与 CI/CD。