Kafka 消息体 JSON 字段增删时，生产消费两端版本不一致如何做到向前向后兼容

【背景】 我们订单履约链路用 Kafka 3.5（3 节点）传事件，topic order-fulfill 16 分区，消息体是裸 JSON（没有 Avro/Schema Registry），生产端是 3 个微服务版本不一致地灰度发布，消费端 8 实例。最近一次迭代在消息体里新增了字段 refundAmount 和 couponId，同时删掉了旧字段 legacyFlag。

【现象 / 卡点】

1. 消费端旧版本还在跑（灰度没全量），收到带 refundAmount 的新消息时，反序列化直接忽略未知字段，没问题；但生产端旧版本还在发不带这两个字段的消息，消费端新版本取 refundAmount 拿到 null，下游 NPE 兜底逻辑没写全，灰度期出现 3 次空指针告警；
2. 更麻烦的是删 legacyFlag：老生产端还在发这个字段，新消费端已经不再读它，但审计日志里有一段代码 if (msg.get("legacyFlag") != null) 直接取 Map，删字段后这段代码取到 null，触发了一段「兜底回写」的脏逻辑，写脏了 200 多条记录；
3. 我们完全没有 schema 注册/版本管理，字段语义靠口头约定，refundAmount 到底单位是「分」还是「元」，两个团队理解不一致，已经对不上账一次（差 100 倍）。

【已尝试的排查】

• 在消费端给所有新字段加「null 检查 + 默认值」，缓解了 NPE，但治标不治本，字段一多就容易漏；
• 想上 Avro + Schema Registry，但 16 分区、日均 4000 万条、生产端 3 个服务异构（Java / Go），全量迁移成本和风险太大，短期内不想动；
• 想加「消息版本号」字段 v，但不知道新旧消息混跑期怎么判定该走哪套解析逻辑。

【期望得到的答案形态】 希望有踩过「JSON 裸传、无 schema 管理、生产消费版本不一致」坑的同学给工程可落地的方案，最好带具体规则：

1. 字段增删的兼容纪律：新增字段消费端是否必须给默认值？删字段要不要先「双发一个版本周期」再删？有没有明确的 checklist？
2. 单位/语义这类「文档级约定」怎么固化进消息体本身（比如字段名带单位 refundAmountCents），避免靠口头约定；
3. 要不要加 v 版本号或 schemaVersion？加了之后新旧混跑期消费端如何路由到对应解析逻辑，会不会反而更乱？
4. 在不上 Schema Registry 的前提下，有没有轻量的「字段契约 + 自动校验」做法（比如消费端启动时校验必需字段、CI 里做 producer/consumer 字段 diff）？
5. 最好给 2~3 条可复现的排查/校验步骤或一条命令，能让我确认线上生产端到底在发哪些字段版本。

我接受渐进式改造，不追求一步到位上 Avro，重点是灰度混跑期不 NPE、不写脏数据、单位不跑偏。