核心问题是未显式声明serialVersionUID导致新旧节点类兼容性失效，引发InvalidClassException；需通过javap比对UID、检查类加载器及全限定名一致性，并强制为异常类添加语义化serialVersionUID。
滚动升级时自定义异常反序列化中断，核心问题往往出在 serialVersionUID 未显式声明，导致新旧节点加载的类虽同名但 JVM 视为不兼容类型。这类故障隐蔽性强，常表现为部分请求成功、部分报 InvalidClassException 或 ClassNotFoundException，且仅在升级窗口期集中爆发。
确认异常是否真被序列化传输
不是所有异常都会走 JDK 序列化流程。需先验证它是否参与了跨进程数据流转：
- 检查调用链：堆栈中是否出现
ObjectInputStream.readObject、ObjectOutputStream.writeObject或框架封装痕迹（如 Dubbo 的RpcException透传、RocketMQ 的Message.getHeaders().get("exception")） - 查看框架行为：Dubbo 2.x/3.x 默认序列化业务异常；Spring Cloud Stream 错误处理器可能将异常包装进可序列化容器；而纯 REST 接口通常只返回 JSON 错误体，不涉及对象序列化
- 抓包或日志取证：在网关或消费者端开启 wirelog（如 Netty 的
LoggingHandler），确认传输载荷中是否含二进制异常对象
比对新旧节点的 serialVersionUID 和字节码
滚动升级中，旧节点用老代码序列化，新节点用新代码反序列化。若异常类未声明 serialVersionUID，JVM 会基于类结构生成哈希值——哪怕只是改了一个注释、调整了方法顺序，哈希就变，直接拒识。
- 在新旧环境分别执行：
javap -s -p com.example.YourBizException，对比输出中的serialVersionUID值是否一致 - 用
diff或 IDEA 的 “Compare Class Files” 功能比对两端.class文件：重点关注字段签名、编译器版本（JDK 17 编译的类在 JDK 11 环境可能因字节码格式差异加载失败） - 特别注意：Maven 多模块中，异常类若被多个 module 引入，可能因依赖传递路径不同，导致 classpath 中存在同名但结构不同的类副本
检查类加载隔离与路径一致性
即使类名、包名、serialVersionUID 全部相同，若由不同 ClassLoader 加载，JVM 仍判定为两个独立类型。
- 在反序列化失败节点打印：
YourBizException.class.getClassLoader()，确认是否来自应用主 jar，而非 shared lib、容器插件目录或 OSGi bundle - 排查 Spring Boot Fat Jar 场景：嵌套 jar 中的类与外部依赖 jar 中同名类冲突，可能导致加载顺序错乱
- 验证类全限定名是否被硬编码进序列化流：旧版存的是
com.old.exception.BizException，新版已迁至com.new.exception.BizException，即便内容一致，也会触发ClassNotFoundException
修复与防御建议
短期止血靠回滚或灰度冻结，长期必须从设计源头规避：
- 所有自定义异常类强制添加：
private static final long serialVersionUID = 1L;（建议用语义化版本号，如20260500L） - 禁止通过序列化方式跨服务传递异常——改用标准错误码 + 业务消息体（如
{"code":"ORDER_TIMEOUT","message":"订单超时"}） - 升级前做兼容性验证：用旧版本序列化一个异常实例，存为
test.ser，再用新版本代码尝试反序列化，提前暴露问题 - 在 CI 流程中加入字节码一致性检查脚本，比对关键异常类在构建前后是否发生变化
