Avro 枚举类型在 Schema 演进过程中，默认情况下并不支持新增 Symbol 的向后兼容读取，即使声明了 default 值也无法自动生效。真正实现兼容的前提是使用二进制格式，并配合正确的 Reader / Writer Schema 解析机制，而非直接采用 JSON 解析。
先说一个核心结论：Avro 枚举的向后兼容性，远比表面上看起来要复杂。不少刚接触的开发者容易踩坑，以为在 Schema 中添加一个新枚举值，再配一个 default 就能万事大吉。结果代码运行时，错误一个接一个——尤其是那个“Unknown symbol in enum BLACK”的异常。
其实，这个问题的根源不在于 Avro 支不支持枚举扩展，而在于你究竟用什么格式来处理数据。关键在于区分两件事：数据是如何序列化的，以及Schema 是如何被解析的。
✅ 正确的兼容模式：二进制格式 + ResolvingDecoder
Avro 的“完全兼容性”（Full Compatibility）有一个硬性前提：Writer Schema 写出的数据，Reader Schema 必须能安全地读回。而这个机制的核心，是二进制编码格式。
二进制格式中，枚举值存储的不是字符串，而是整数序号（ordinal）。例如 BLUE=0, YELLOW=1, BLACK=3。当 Reader Schema 中没有 BLACK 这个枚举项时，Avro 的 ResolvingDecoder 会检测到序号越界，然后自动触发字段的默认值回退逻辑——也就是你之前把 UNKNOWN 设为 default 的那个值。整个过程无缝完成，完全不需要手动处理。
使用 avro-tools 做一个快速验证就能清楚：
# 用 v2 Schema 写入包含 "yellow" 的数据（序号为 4）
java -jar avro-tools-1.11.1.jar fromjson --schema-file v2.avsc v2.json > v2.avro
# 用 v1 Schema 读取 —— 成功返回 {"color": "unknown"}
java -jar avro-tools-1.11.1.jar tojson --reader-schema-file v1.avsc v2.avro
看明白了吗？同一个二进制文件，使用 v1 的 Reader Schema 去读取，系统会自动识别不认识的枚举值并赋予默认值。这才是真正的兼容模式。
❌ JSON 格式为何失败？
反观 JSON 格式，问题就出在它的自描述本性上。你的 Java 代码中，如果使用 JsonDecoder 直接解析 JSON 字符串，比如这样的场景：
var jsonDecoder = DecoderFactory.get().jsonDecoder(TreeRecord.SCHEMA$, resourceAsStream); // ❌ JsonDecoder 逐字匹配 symbol 名称，不查序号，不触发 default 回退
JsonDecoder 是逐字匹配的：它只认字符串字面量，完全不管序号这回事。你给它一个 "BLACK"，它在 Reader Schema 的 symbols 列表里搜不到，直接抛出 AvroTypeException。你声明的 default 值在这条路径上，根本不会被用到。这也就解释了为什么很多人以为添加了 default 就能安全兼容，结果还是崩了——因为 JSON 解析压根不走 default 回退流程。
所以，结论很清晰：default 值仅在二进制格式下配合 ResolvingDecoder 才有效，在 JSON 格式下纯粹是个摆设。
✅ 解决方案：统一使用二进制协议
搞清楚原因之后，解决方案就很明确了：
- 生产端：始终使用 BinaryEncoder 来序列化数据。如果你们在采用 Confluent Schema Registry，直接用它来管理 Schema，这已经是标准做法；
- 消费端：使用 SpecificDatumReader + BinaryDecoder，并且一定要提供 Writer Schema（比如从 Schema Registry 获取），这样才能激活 ResolvingDecoder，让 default 值发挥真正的作用；
- 如果实在绕不开 JSON：不要直接解析。先把 JSON 转成一个 GenericRecord（需要完整的 Writer Schema），然后用 GenericDatumWriter 序列化成二进制数据，最后再用 Reader Schema 去反序列化。虽然多了两步，但这是唯一能保证兼容的方式。
⚠️ 注意事项与最佳实践
当然，实际落地时还有几点需要特别注意：
- 枚举设计原则：强烈建议始终将 UNKNOWN 或 UNRECOGNIZED 这类通用项放在枚举的第一个位置（索引 0），并显式设置为 default。这样未来无论新增还是删除枚举值，你的系统都有兜底方案，不至于一上来就崩溃；
- Schema Registry 配置：启用 FULL 兼容性级别。在注册新版本的 v2 Schema 时，确保它能通过兼容性检查，别等上线了才发现不兼容；
- Java 代码修正示例：如果你还在踩坑，直接把这个例子拿过去用——
// ✅ 正确：使用二进制流 + ResolvingDecoder（需 Writer Schema） InputStream binStream = ...; // 二进制 Avro 数据 DatumReader
reader = new GenericDatumReader<>(writerSchema, readerSchema); Decoder decoder = DecoderFactory.get().binaryDecoder(binStream, null); GenericRecord record = reader.read(null, decoder); // 自动将未知 enum 映射为 default
总结一下：Avro 枚举的向后兼容能力，不是那种声明一下就能自动生效的“语法糖”。它深度绑定在二进制序列化语义的设计中。要想真正实现 Full Compatibility，就得放弃直接用 JSON 解析 Reader 的路径，全面拥抱 Schema-driven 的二进制协议。这不仅是技术选择，更是架构设计上的必要决策。
