EnumConstantNotPresentException在新版服务端反序列化含已删枚举项的旧数据时触发，因JVM调用Enum.valueOf查不到对应常量；需在反序列化入口拦截处理，而非业务层try-catch。

这个异常不会在旧版客户端反序列化“新枚举值”时触发，恰恰相反：它发生在新版服务端（或 JVM）反序列化旧版客户端保存的数据时，而该数据中包含当前版本已删除或重命名的枚举常量。

为什么旧客户端 + 新枚举会出问题？

Java 枚举的默认序列化机制不保存字段或逻辑，只保存枚举常量的类名 + 常量名称字符串。反序列化时，JVM 直接调用 Enum.valueOf(YourEnum.class, "OLD_CONSTANT") 查找匹配项。如果新版枚举里已删掉 OLD_CONSTANT，就抛 EnumConstantNotPresentException。

旧客户端本身不会“看到”新值——它根本不知道新值存在；它只负责把老数据发出去或存下来。真正出问题的是接收/加载这些老数据的新环境。

典型触发场景

• 用户配置存在 Redis 或数据库中，格式是 ObjectOutputStream 序列化的对象，含 Status.ACTIVE
• 上线新版本，把 Status 枚举删掉了 ACTIVE，改用 ENABLED
• 服务重启后尝试从 Redis 反序列化旧配置，ObjectInputStream 找不到 ACTIVE → 立即抛异常
• Spring Boot 应用启用 HTTP Session 持久化，用户会话里存了带枚举的 DTO；升级后老会话恢复失败
• Dubbo 或 RocketMQ 消费者收到历史消息，消息体是 JDK 序列化对象，含已下线的订单状态枚举

关键特征帮你快速定位

这个异常不是你代码主动调用 valueOf() 报的，而是藏在 readObject() 内部，堆栈里通常看不到你的业务方法。常见表现：

• 异常堆栈顶层是 ObjectInputStream.readEnum、ObjectInputStream.resolveEnum 或 AnnotationParser.parseEnumValue
• 异常信息里明确带两个字段：enumType=class com.example.Status 和 constantName="ACTIVE"
• 不是 IllegalArgumentException，但它是其子类；捕获 IllegalArgumentException 有时能兜住，但不严谨

不推荐的应对方式

别在业务层写 try-catch Enum.valueOf() 就以为解决了——那只能覆盖你手动调用的场景，对真正的反序列化入口无效。也不要指望“让旧客户端升级”，因为老数据已经躺在库里了。

真正要做的，是在反序列化流程的最上游拦截并提供兼容逻辑，比如自定义 ObjectInputStream、注册 Jackson 的安全反序列化器，或者从根本上改用 @JsonValue + 整数 code 的持久化方式。