存量系统迁移，用小变更保持主干可用

存量系统迁移，用小变更保持主干可用

大 MR 会放大冲突、评审盲区和回滚难度。把迁移拆成可独立验证的小步骤：先引入接口与测试，再放入新实现，最后用特性开关切流。每一步都能在不影响主干的情况下回退。

特性开关应有默认值、所有者、失效日期和观测指标。它是发布控制手段，不应长期替代架构决策；旧分支确认不再使用后要删除，避免组合爆炸。

if flags.Enabled("new-scorer", user.ID) { return newScorer.Score(ctx, input) } return oldScorer.Score(ctx, input)

持续同步主干可降低冲突，但 rebase 会改写个人分支历史，协作分支需先约定流程。合并前运行受影响模块的测试和兼容性检查；切流后观察错误、差异与回退能力，再清理旧代码。

迁移结束也要有明确的收尾条件：新旧实现的对比观察结束、开关已移除、旧数据处理完成、文档与告警指向新路径。没有这些条件，临时兼容层会长期留在主干，后续每次改动都得同时理解两套行为。小变更并非拖慢交付，而是把不可逆的风险拆成可检查的步骤。