混合版本才是常态
滚动发布期间，一部分实例运行旧构建，一部分运行新构建；跨区域故障转移时，新控制面可能与旧节点配合；移动客户端要花几个月才完成升级。版本偏斜不是需要消灭的异常，而是任何分布式系统的稳定状态，必须被显式设计。
兼容窗口
每个接口都需要明确的兼容窗口：允许多少个版本共存、共存多久。例如 Kubernetes 会发布偏斜策略，规定控制面与节点版本可以相差多少。内部 API 同样需要把这件事写下来，因为一旦出现两个团队，「我们总是一起发布」就不再成立。
数据才是难点
代码通常可以两个版本同时跑，数据不行。新版本写入新列、新枚举值或新消息字段，会产生旧版本无法理解的状态。采用扩展—收缩式迁移：先新增，再部署读取方，回填数据，最后在后续版本中删除。例如，写入旧代码会拒绝的状态值，会把一次回滚变成一次故障。
测试偏斜
测试你真正支持的组合：新对旧、旧对新，以及两者对共享状态。契约测试能发现协议层破坏，回放录制流量能发现行为层破坏。把偏斜场景加入发布检查清单，因为默认测试套件只会验证版本一致的组合。
与原子升级的对比
原子升级通过一次性切换避免偏斜，代价是停机或复杂的切换流程。增量升级接受偏斜以保持可用性。只有把兼容性验证清楚而不是假设成立，并且用新版本写入的数据验证回滚，这笔交易才安全。