Monorepo 里的分层检查策略
多包仓库把多个模块放在同一仓库，检查策略要按边界拆分：每个包有自己的配置与忽略清单，公共规则抽成共享预设由各包继承，避免各包规则悄悄分叉。执行层面只对变更涉及的包启动检查，而不是全仓扫描。这样做的目的是让检查时间随变更规模增长，而不是随仓库规模增长。
策略要点
| 边界 | 按包或目录独立配置，规则差异写在本地 |
|---|---|
| 共享 | 公司或仓库级预设，通过继承下发统一规则 |
| 提速 | 只检查变更包及其依赖方（受影响集） |
| 一致性 | 预设升级后所有包同步受益，避免版本漂移 |
典型使用场景
- 仓库包含十几个包：全量检查要十几分钟，改为变更集驱动后压到分钟级
- 包之间依赖关系复杂：根据依赖图计算受影响包，避免只检查变更包而漏掉下游
- 不同包技术栈不同：共享预设只放通用规则，语言特有限制放在各自包里
- 多团队共用一个仓库：各团队维护自己的包配置，公共规则由平台团队维护
- 本地开发提速：开发者只跑自己包的检查，提交前钩子同时校验受影响包
受影响集的计算思路
受影响集的计算思路
# 计算流程
1. 从 git diff 得到变更文件列表
2. 把文件映射到所属包目录（包清单由工作区配置提供）
3. 在依赖图上做反向闭包，得到依赖这些包的下游包
4. 仅对受影响包执行检查、构建与测试
5. 仓库级配置或共享预设变更时，视为全量受影响配置分层对照
| 层级 | 内容 | 变更影响 |
|---|---|---|
| 仓库级预设 | 规则集、格式化选项、忽略清单基线 | 变更即全量生效，需要全仓回归 |
| 包级配置 | 语言特有限制、目录忽略、覆盖规则 | 只影响本包 |
| 工作区配置 | 包清单与依赖关系声明 | 变更影响受影响集计算，需谨慎 |
| CI 配置 | 检查触发条件与缓存策略 | 变更影响流水线行为，需评审 |
共享预设的升级要单独提交并附迁移说明：规则收紧会让多个包同时变红，混在功能提交里无法判断红项来自代码还是规则。
受影响集计算的前提是依赖声明准确。若包之间的隐式依赖（例如通过共享脚本或环境变量耦合）没有被声明，反向闭包会漏掉下游包，出现本地通过而集成失败的情况。
落地检查清单
- 每个包的配置文件与依赖声明齐全，新增包时有模板可依
- 仓库级预设变更时触发全量检查
- 受影响集脚本本身有测试，避免依赖图解析错误静默漏包
- 忽略清单里的每一项都能说明原因