用分阶段迁移保留兼容性

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

使用场景

多个包使用共享字段 timeout，你要迁移到 timeoutMs。教学契约要求旧调用者在迁移期间可用；同时传两字段且值不同须报冲突。直接改名会一次打断所有未迁移调用者，适合用扩展→迁移→收缩。

具体做法

先增加新形式并保留明确旧形式兼容与冲突规则，验证两者行为。按调用者清单分批迁移，各批依赖扩展完成并有覆盖检查。全部需要保留的调用者迁移、兼容与回退条件核对后才删除旧形式。无法独立保持绿色的真实情况，明确集成分支与最终验证节点，不假报各批可交付。

反例

直接把共享字段改成 timeoutMs，让其他包一直失败到最后集成；删掉失败调用者或静默忽略旧字段以显示构建通过。

改进写法

按教学兼容契约：扩展支持 timeoutMs 与旧 timeout，相同值可接受、不同值报告冲突；验证旧调用仍可用。逐包将调用者迁移到新字段并检查，清单未归零不删除旧支持。收缩节点依赖全部迁移与兼容核查。如果有不能独立通过的批次，声明只在最终集成节点验证，不把临时失败称为逐批绿色。

为什么这样改

新旧并存给调用者迁移窗口，清单与依赖把删除条件变成可检查事实。显式冲突规则避免两形式同时存在时猜哪个值，而真实集成门不掩盖阶段限制。

如何验证

教学测试包括旧单字段、新单字段、双字段同值和双字段冲突；迁移清单有残留旧消费者时收缩不得执行。

最终检查旧支持删除后的全链行为；仅搜索字符串零出现不能证明外部消费者已迁移。本篇不做真实配置迁移。

适用边界

字段解析、默认与双值规则是教学约定，实际 API 必须决定自己的兼容语义。扩展收缩不免除数据迁移、外部消费者或版本发布约束，也不证明所有广泛修改都适合相同批次。