InvalidClassException 的核心是反序列化时类的 serialVersionUID 不匹配，需比对 stream 中的 UID 与本地类计算出的 UID，检查字节码一致性、ClassLoader 加载路径及实际序列化协议。
InvalidClassException 的核心是反序列化时类的版本不匹配，排查要从“流里存的是什么”和“当前加载的是什么”两个角度交叉验证。
看报错信息里的 UID 差值
异常堆栈中一定会出现两行关键数字：
- stream classdesc serialVersionUID：序列化数据里记录的旧版本号
- local class serialVersionUID：当前 JVM 加载的类算出的新版本号
直接把这两个值抄下来，比如 -6768332863867503700 和 -5116586570513707805，它们不相等就是直接原因。如果类没显式声明 UID，那说明类结构已变——哪怕只是加了个空行、改了方法顺序，JVM 自动生成的哈希就不同。
用 javap 比对真实字节码
别信源码看起来一样，得看编译后的 .class 文件是否真一致：
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 在出问题的两端（如旧服务节点、新服务节点）分别执行：
javap -s -p com.example.YourClass - 重点核对输出里的
serialVersionUID行是否完全相同 - 再对比字段签名（descriptor）、方法表、常量池——尤其注意 IDE 自动生成的桥接方法、$accessor 方法是否多出来
常见陷阱：同一份代码用 JDK 11 和 JDK 17 分别编译，生成的 class 文件结构不同，UID 自然不同。
查类是从哪加载的
即使类名、包名、UID 全对，如果被不同 ClassLoader 加载，JVM 也认为是两个类：
- 在反序列化失败处加一行日志：
System.out.println(YourClass.class.getClassLoader()); - 同时打印：
System.out.println(YourClass.class.getProtectionDomain().getCodeSource()); - 确认路径指向的是你预期的 jar 包，而不是 Tomcat shared lib、Spring Boot fat jar 的嵌套路径、或某个老版本依赖副本
特别留意 Maven 多模块项目：异常类若被 A 模块定义、又被 B 模块通过 compile 依赖引入，而 B 又被 C 以 provided 引入，极易导致 classpath 中存在同名但字节码不同的多个副本。
确认对象真的走的是 Java 序列化
不是所有“传异常”都触发 Serializable 流程：
- Dubbo 默认会序列化业务异常；Spring Cloud Stream 的 ErrorMessage 会；但 REST 接口返回的 JSON 错误体不会
- 搜日志里有没有
ObjectInputStream.readObject或ObjectOutputStream.writeObject的调用栈 - 抓网络包或开启框架 wirelog（如 Netty LoggingHandler），看传输内容是不是二进制流，而非纯文本
如果实际走的是 JSON 或 Protobuf，那 InvalidClassException 就是干扰项，真正问题在序列化协议配置或字段映射上。
