必须显式声明serialVersionUID并确保JDK版本一致，否则跨版本反序列化会失败；JDK 25中LocalDate等类的Class对象序列化因字段类型变更而断裂；推荐使用Protobuf或JSON替代原生序列化。
不能默认兼容，必须主动控制 serialVersionUID 并验证运行时环境一致性。
serialVersionUID 不显式声明就等于放弃兼容权
OpenJDK 升级（比如从 8→11、17→25）本身不直接破坏序列化，但会间接触发失效：JVM 对类结构的哈希计算逻辑可能因编译器实现、字节码生成细节或内部字段类型变更而不同。一旦你没写 serialVersionUID，JDK 就用内置算法算一个——这个值在 OpenJDK 8 和 OpenJDK 17 下对同一份源码很可能不一样，反序列化时立刻抛 java.io.InvalidClassException。
- 最稳妥做法是所有可序列化类都手动声明
private static final long serialVersionUID = 1L; - 仅当发生**不兼容变更**（如字段类型从
int改成String、删掉非transient字段且未配ObjectStreamField映射）才递增版本号 - 别信 IDE 自动生成的长哈希值（如
-5448724816396875494L），它只是模拟“不声明”的行为，不是稳定标识
JDK 25 的 java.time 类存在真实序列化断裂
JDK 25 中 LocalDate、YearMonth 等类的私有字段类型被从 short 改为 byte（month 和 day），导致其 Class 对象的序列化字节流与 JDK 24 及之前版本不兼容。注意：这是 Class 对象本身的序列化失败，不是实例对象；但如果你在分布式缓存、RMI 或某些监控框架中序列化了 LocalDate.class 这种引用，就会在 JDK 25 环境下反序列化时报 InvalidClassException。
- 实例对象（如 new LocalDate(2025, 1, 1)）仍可通过代理模式正常反序列化
- 问题只影响跨 JDK 版本保存/加载
Class引用的极少数场景 - 目前无运行时开关可绕过，需确保序列化端和反序列化端 JDK 大版本一致
第三方序列化框架（如 Kryo、FST）不受 JDK 版本直接影响，但依赖类结构
如果你用的是 Kryo 或 FST 而非原生 ObjectOutputStream，它们不走 Java 标准序列化协议，因此不校验 serialVersionUID，也不会因 JDK 25 的字段类型变更而失败——前提是类定义本身没变。但一旦升级 JDK 后重新编译代码，字节码结构可能变化（比如 Lombok 生成的桥接方法、Kotlin data class 的合成字段），这些框架仍可能因字段顺序、名称或访问性差异而读错数据。
- 禁止在 DTO 上用
@Data+ 原生序列化，手写readObject/writeObject更可控 - 跨 JDK 版本部署时，建议统一使用 Protobuf 或 JSON 这类语言中立格式替代 Java 原生序列化
- 若必须用原生序列化，至少保证序列化端和反序列化端使用相同 JDK 发行版（如都用 Eclipse Temurin 17.0.13+7）
真正要保序列化兼容，得盯住三件事：类源码是否一致、serialVersionUID 是否显式且稳定、运行时 JDK 版本是否对齐。JDK 升级只是放大器，不是根源——根源是你有没有把序列化当成契约来管理。
