核心解法是切断枚举跨进程传输路径，RPC只传字符串或整数，入口处转换为枚举，共用Protobuf定义并校验一致性，兼容演进+运行时兜底告警。
核心解法不是“升级枚举”，而是切断枚举实例跨进程传输的路径——让RPC只传可序列化的原始值，不在服务边界上暴露Java枚举类型本身。
用字符串/整数代替枚举实例传参
Java枚举本质是类，含静态方法、构造器和状态，无法跨JVM安全序列化。一旦Dubbo或gRPC把OrderStatus.SHIPPED直接塞进请求体，下游若枚举定义不同（比如少了该常量），反序列化就会失败或静默错配。
- 服务接口定义统一用
String或int接收状态字段，而非OrderStatus - 在入口处（如Controller或RPC Provider）做一次转换：
OrderStatus.fromCode(request.getStatus()) - 响应也只返回
status: "shipped"这类字符串，前端或下游按约定映射
前后端共用枚举定义文件（非运行时类）
避免各端各自定义同名枚举却字段不一致。推荐方式：用JSON Schema或Protobuf enum生成多语言枚举代码。
- 定义一个
status.proto，含enum OrderStatus { PENDING = 0; SHIPPED = 1; } - 用
protoc生成Java/TypeScript/Python对应枚举，保证字段名、序号、语义完全一致 - 禁止手动在Java里新增
DELIVERED却不同步更新proto——CI流水线应校验proto与生成代码一致性
服务间契约必须声明枚举演进规则
不是“只要加字段就行”，而是明确哪些变更算兼容：
立即学习“Java免费学习笔记（深入）”；
- ✅ 允许：新增枚举项（保留旧项编号不变）、为现有项添加注释或描述字段
- ❌ 禁止：删除/重命名已有项、修改已有项的序号、改变枚举类继承关系
- ⚠️ 警惕：字段名大小写变更（如
PENDING→pending）在JSON反序列化时可能被忽略，但逻辑已错
运行时兜底：提供默认映射与告警机制
即使有规范，线上仍可能出现未知枚举值（如新上游发来旧下游未识别的状态）。
- 转换方法
fromCode()不抛异常，而是返回UNKNOWN枚举项，并记录WARN日志 - 监控指标：统计
unknown_status_count每分钟突增，触发告警——这是版本不一致的早期信号 - 灰度发布时，要求新枚举值先在日志中标记“preview”，确认下游适配完成再正式启用
