按风险分批迁移并验证构建

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

共享库 core 要升级，service-a 和 worker-b 都依赖它。教学依赖为 core→两个调用者，service-a 风险更高；你已有当前版本的构建基线和待保留的本地改动。不能一次改所有调用者后靠无限全构建掩盖失败来源。

具体做法

先记录依赖、风险、基线与保护范围。满足依赖顺序后，在可执行节点中优先验证高风险调用者；按可隔离批次修改并运行覆盖检查。失败时保留错误和该批状态，诊断前不推进依赖未满足的批次。需要回退时仅处理可识别且获准回退的本批改动，不清理其他人的工作。

反例

同时改 core、service-a、worker-b，反复跑全构建。任何失败调用者都从清单删掉，最后把剩余通过项叫迁移完成。

改进写法

按上述图先迁移并检查 core，再检查风险较高的 service-a，随后处理 worker-b；各批保存基线、修改和覆盖结果。前置未通过时不推进依赖批次。重复无进展错误停止该轮并报告，保留 diff；回退只能在授权范围内隔离本批，不删除既有本地工作。报告所有调用者状态，失败项不能从覆盖清单消失。

为什么这样改

有界批次使失败与改动范围对应，依赖顺序避免下游在未满足前提上继续。风险排序帮助先验证重要路径，而状态台账保持迁移未完成部分可见。

如何验证

示意台账：core 通过、service-a 失败、worker-b 待检查。整个迁移仍未完成，先诊断 service-a；若 core 失败，两调用者不能基于它宣称新版本通过。

检查此前通过证据与版本相符，失败和未查项保留，回退没有覆盖无关改动。

适用边界

风险不能越过真实依赖；独立调用者是否可先继续取决于实际前置与资源。一次构建通过不证明业务兼容，需相关行为检查。批次范围是教学安排，原文未确认。