Java异常类必须实现Serializable，因为Throwable实现了该接口，确保异常可跨JVM传输；未显式声明serialVersionUID会导致结构变更时反序列化失败；含非transient不可序列化字段会抛NotSerializableException。
Java异常类为什么必须实现 Serializable
Java异常类默认需要序列化，根本原因在于：所有标准异常（如 Exception、RuntimeException）都继承自 Throwable，而 Throwable 类本身实现了 Serializable 接口。这意味着任何自定义异常若不显式声明，也会自动具备序列化能力——但前提是它没有包含不可序列化的字段。
自定义异常不加 serialVersionUID 会怎样
不显式定义 serialVersionUID 时，JVM 会根据类名、接口、成员方法和字段等自动生成一个。一旦类结构变动（比如新增字段、修改访问修饰符），生成的 UID 就会变化，导致反序列化失败，抛出 InvalidClassException。
- 常见错误现象：
java.io.InvalidClassException: MyException; local class incompatible: stream classdesc serialVersionUID = 123..., local class serialVersionUID = 456... - 使用场景：RMI 调用、分布式日志传输、Jetty/Tomcat 的异常页面缓存、某些监控 SDK 序列化异常上下文
- 建议始终显式声明：
private static final long serialVersionUID = 1L;
或用 IDE 自动生成带时间戳的值（如8290739329384729384L）
哪些字段会导致异常无法正常序列化
只要异常类中添加了非 transient、非 static 且类型不可序列化的字段，就会在序列化时抛出 NotSerializableException。
- 典型踩坑点：
private Connection dbConn;、private ThreadLocal、context; private Logger logger; - 解决方案：用
transient修饰这些字段，或确保其类型实现Serializable - 注意：
cause（即initCause()设置的嵌套异常）会被自动序列化，无需额外处理
writeObject 和 readObject 在异常类中要不要重写
绝大多数情况下不需要重写。除非你有特殊需求，比如想过滤敏感字段（如密码、token）、统一填充诊断信息，或兼容旧版本序列化格式。
立即学习“Java免费学习笔记（深入）”；
- 重写风险：容易破坏
Throwable内部状态（如stackTrace、suppressedExceptions），导致反序列化后printStackTrace()不完整或getSuppressed()返回空数组 - 如果真要定制，必须调用
defaultWriteObject()/defaultReadObject()并严格保持字段顺序与父类一致 - 更安全的替代方案：通过构造函数参数传递上下文，而非靠序列化字段承载业务数据
transient 的 ExecutorService 字段，就足以让整个异常对象在远程调用中静默失败。 
