Nx 单体仓库工程化

当 CI 从半小时拖到一小时

多包仓库里改一行共享代码，CI 就重新跑全量测试和构建，时间从半小时拖到一小时。更难受的是：你不敢确定这次改动会影响哪些应用，只能全量回归，或者凭感觉挑几个跑，结果漏测又上线后炸了。

Nx 的核心逻辑是先把仓库拆成可计算的依赖图：每个子项目都有显式的 project.json，依赖方向必须单向，库和应用边界清晰。这样工具能静态分析“改了 @core/utils，哪些 web 和 mobile 会受影响”，再通过 nx affected:build、nx affected:test 只跑真正需要验证的部分，而不是全仓扫描。

把仓库拆成可计算的依赖图

• 依赖图是基础：Nx 通过读取 project.json 里的 target 和依赖声明，构建项目间关系。隐式循环依赖会导致图失准，所以边界定义必须明确——哪些是可复用的库，哪些是顶层应用，依赖方向不能反。
• 受影响命令是核心：nx affected:build、nx affected:test 只处理改动相关项目，配合分布式缓存（本地与 CI 共享）和任务编排（独立任务并行，依赖任务拓扑执行），流水线时间能从小时级压到分钟级。
• 落地步骤要扎实：

1. 用 Nx 初始化，让每个子项目有 project.json；
2. 定义库和应用边界，确保依赖单向；
3. 用 nx affected 替代全量命令；
4. 开缓存，命中直接复用产物；
5. 配并行，让独立任务同时跑。

适用边界与注意点

不是所有仓库都适合强单体化。如果子项目间隐式循环依赖，依赖图会失准；缓存键未包含输入（比如环境变量或构建参数），会命中过期结果；把本可独立的小项目强行塞进单体，反而增加耦合和构建负担。

工具能帮你算清影响面，但仓库结构和边界定义仍需人工把控。小团队协作不密集时，单体可能比多仓库更重；大团队需要频繁跨项目改动时，Nx 的依赖图和 affected 命令才是真杠杆。