目标
schema 变更在生产者手里改起来很局部，执行起来却摊派到每个消费者头上。先声明兼容性等级、拿消费者清单做评审、把破坏性变更拆成“扩展—迁移—收缩”三段，原本的“旗日切换”就变成对所有相关方都无感的过程。
步骤要点
- 先分类兼容性：向后兼容（加可选字段）、向前兼容（忽略未知字段）、破坏性，等级决定流程重量。
- 超出纯增量一律对照消费者清单评审：逐个确认对该变更的容忍度并取得确认。
- 破坏性变更先扩展：新字段或新表与旧的并存，生产者在过渡窗内双写，旧消费者照常工作。
- 消费者按各自节奏迁移：窗口内逐个切换，双读对比验证输出符合预期。
- 窗口关闭后才收缩：全部消费者迁移完成并过了约定时长，才在最后一次公告式变更里删除旧字段。
排错提示
加了个“必填字段”把严格校验的下游打挂说明兼容性不能只看语法，评审要拿消费者清单逐个确认；双写期间新旧值不一致是映射逻辑有 bug，恰好是双读对比的价值所在；旧字段删了还有消费者在用是收缩太急，把“窗口时长 + 迁移完成证据”设为删除前置条件。
适用边界
双写窗口增加生产端成本与存储，超长窗口要评估代价与收益的平衡点；消费者不清点、无注册表的体系要先建清单再谈治理。
代码示例
event: order.created v3 (breaking)
compatibility: BREAKING (renames amount_cents)
plan:
1. expand v4: add total_cents (dual-write)
consumers on v3 keep working
2. migrate consumers (their schedule):
analytics 10-24 dual-read diff = 0
billing 10-29 dual-read diff = 0
fraud 11-02 dual-read diff = 0
3. contract v5 (11-09): drop amount_cents
references migration record #447