3、Schema版本管理：版本号策略、向后兼容原则、版本迁移脚本、版本回滚方案

版本管理这事，说白了就是给Schema上个「身份证」。我见过太多团队，一开始觉得版本号无所谓，结果线上出了兼容性问题，查半天不知道哪个版本在跑。嗯，今天咱们就把这块聊透。

3.1 版本号策略：别小看那三个数字

我个人习惯用语义化版本号，格式是 MAJOR.MINOR.PATCH。为什么这么分？因为每个位置代表不同的变更级别。

位置	变更类型	举例	兼容性
MAJOR	不兼容的API修改	删除字段、修改字段类型	不向后兼容
MINOR	向下兼容的功能新增	新增可选字段	向后兼容
PATCH	向下兼容的问题修正	修复字段描述、调整默认值	向后兼容

我在项目中遇到过一种情况：有人把字段类型从 int 改成 string，只改了PATCH版本号。结果下游消费者全部报错。你想想看，这哪是修bug，这是拆桥啊。

3.2 向后兼容原则：别让你的消费者「断粮」

向后兼容，说白了就是「老版本还能用」。我建议你记住这几点：

• 只能加字段，不能删字段——老消费者不认识新字段，但不会报错
• 新增字段必须是 optional——别一上来就 required，老数据没有这个字段
• 字段类型只能放宽，不能收紧——比如 int 可以改成 long，但不能反过来
• 默认值要合理——新字段的默认值不能破坏老逻辑

为什么会这样？因为Schema不是给你一个人看的，它是你和所有消费者之间的契约。你改契约，得保证对方不违约。

3.3 版本迁移脚本：从旧到新的「桥梁」

版本迁移脚本，就是帮你把数据从旧Schema「翻译」到新Schema。我一般分三步走：

1. 读旧版本——解析旧Schema结构
2. 做转换——字段映射、类型转换、默认值填充
3. 写新版本——输出符合新Schema的数据

举个例子，假设旧版本有个 full_name 字段，新版本拆成了 first_name 和 last_name：

// 迁移脚本示例（伪代码）
function migrateV1ToV2(oldRecord) {
  const nameParts = oldRecord.full_name.split(' ');
  return {
    first_name: nameParts[0],
    last_name: nameParts.slice(1).join(' '),
    // 其他字段原样保留
    ...oldRecord
  };
}

3.4 版本回滚方案：给自己留条后路

回滚，是每个架构师都不想做但必须会的事。我建议你准备三套方案：

方案	适用场景	风险
数据快照回滚	小范围、低频率变更	数据量大时耗时久
逆迁移脚本	有准备的回滚	脚本可能写错
双写双读	高可用场景	架构复杂、成本高

我个人最推荐逆迁移脚本。因为它在迁移脚本发布时就写好，测试通过再上线。回滚时直接执行，不用临时想方案。

3.5 版本管理的核心流程

下面这张图，是我在项目里总结的版本管理流程。你看一遍就能明白：

你看，流程其实不复杂。关键是在「评估兼容性」这一步想清楚，别急着动手改。

3.6 避坑指南：我踩过的几个坑

• 版本号跳级：有人从 v1.0.0 直接跳到 v3.0.0，中间版本全丢了。回滚时找不到中间状态的脚本。我建议每次只升一级，别跳。
• 迁移脚本不测试：写完了直接上线，结果数据全乱了。迁移脚本必须和单元测试一起提交，覆盖正常数据和边界数据。
• 回滚方案不验证：以为逆迁移脚本写对了，结果回滚时发现字段映射反了。我建议每次发布前，在预发环境完整走一遍「迁移→回滚→再迁移」的流程。

好了，版本管理这块就聊到这儿。记住一句话：版本号是承诺，迁移脚本是桥梁，回滚方案是底线。把这三点做好，Schema治理就稳了一半。