InvalidClassException 的核心是类版本不一致导致序列化契约断裂，需显式声明并稳定维护 serialVersionUID，严格区分兼容/不兼容变更，规避默认机制脆弱性，优先采用 schema 显式的序列化方案。
InvalidClassException 的核心问题是类版本不一致，不是程序逻辑错误，而是序列化契约断裂。解决重点不在捕获异常，而在提前统一版本、控制结构变更、规避默认机制的脆弱性。
显式声明并稳定维护 serialVersionUID
所有实现 Serializable 的类必须手动写死 serialVersionUID，不能依赖 IDE 生成后就放任不管。
- 用 private static final long serialVersionUID = 1L; 或带业务含义的值（如 20240101L），避免与自动生成值冲突
- 当发生不兼容变更（删字段、改类型、调整继承关系）时，主动递增该值（如从 1L 改为 2L）
- 当仅做兼容变更（加 transient 字段、加静态方法、重命名 getter）时，保持 UID 不变
- 父类和子类都需独立声明 UID；若父类未声明而子类声明了，继承链校验可能失败
警惕类路径与结构微调引发的 UID 漂移
即使代码肉眼没变，编译环境差异也可能让默认 UID 突然变化。
- JDK 8 和 JDK 17 对同一源码计算出的默认 UID 可能不同
- IDE 自动格式化、重排 import、添加注解（如 @Deprecated）都可能影响哈希结果
- Lombok 的 @Data 在字段变动时会隐式改变默认 UID，务必配合显式声明
- 构建工具缓存或多机编译导致字节码不一致，建议在 CI 中加入检查：扫描未声明 UID 的 Serializable 类并报错
字段类型变更必须走迁移而非绕过
int → long、String → Integer 等类型改动是硬性不兼容，强行改 UID 或设 transient 无法真正解决问题。
立即学习“Java免费学习笔记（深入）”；
- 安全做法：用旧版本代码读出全部序列化数据，转成 JSON/YAML/Map 等中间格式，再由新版本重建对象并重新序列化
- 渐进方案：保留原字段，新增兼容字段，在 readObject() 中手动转换赋值
- 长期策略：放弃 Java 原生序列化作持久存储，改用 Protocol Buffers、Jackson JSON 等 schema 显式、语言中立的格式
类名或包名变更需配套映射或重建
序列化数据里固化的是全限定类名（如 com.old.User）。迁移到 com.new.User 后，JVM 会直接报 “class not found”，哪怕结构完全一样。
- 临时应对：继承 ObjectInputStream，重写 resolveClass()，将旧类名映射到新类（仅限语义完全等价时）
- 推荐做法：把序列化视为短期传输机制，存量数据通过双版本代码桥接迁移
- 禁止跨大版本直接反序列化；对外暴露的 SDK 接口类，一旦发布就必须冻结 UID 和字段定义
