自定义异常类不是必须实现Serializable，但强烈建议实现；若添加了不可序列化字段或用于跨JVM传输（如RMI、Dubbo），未实现会导致NotSerializableException或InvalidClassException。
自定义异常类必须实现 Serializable 吗？
不是必须，但绝大多数情况下**强烈建议实现**。Java 的 Exception 类本身已实现 Serializable，所以你继承 Exception 或其子类（如 RuntimeException）时，自定义异常默认可序列化——前提是没显式声明 serialVersionUID 且未添加不可序列化字段。
真正踩坑的场景是：你在异常类里加了非 transient 的实例字段，且该字段类型本身不可序列化（比如 Thread、Socket、某些第三方类）。这时即使继承了 Exception，序列化仍会抛 NotSerializableException。
什么时候不实现序列化反而更安全？
当异常仅用于本地方法调用、不跨 JVM 传输、也不存入持久化存储（如日志系统不依赖序列化写盘）时，可不关心序列化。但要注意：
- 使用 RMI、JMX、某些 RPC 框架（如 Dubbo 默认启用序列化）时，异常会在网络间传递，未序列化将直接失败
- Spring AOP 的异常通知（
@AfterThrowing）本身不强制序列化，但若切面逻辑中把异常放入远程队列或缓存，就会暴露问题 - JVM crash dump 或某些监控 agent（如 ByteBuddy 增强）可能尝试序列化异常上下文
serialVersionUID 是必须手动声明的吗？
不是必须，但不声明会有隐式风险。JVM 会基于类结构自动生成 serialVersionUID，一旦你修改了异常类的字段（增删改）、继承关系或实现了新接口，生成值就变——导致反序列化失败，报 InvalidClassException。
立即学习“Java免费学习笔记（深入）”；
推荐做法是显式声明一个固定值：
public class BizException extends Exception implements Serializable {
private static final long serialVersionUID = 1L;
private final int errorCode;
public BizException(int errorCode, String message) {
super(message);
this.errorCode = errorCode;
}
// 注意：如果字段不可序列化，要么加 transient，要么确保其类型可序列化
}
继承 RuntimeException 和 Exception 对序列化有影响吗？
没有本质影响。两者都实现了 Serializable，区别只在是否强制检查（checked vs unchecked）。但要注意：
-
RuntimeException子类常被用于业务逻辑快速失败，容易被忽略序列化需求，上线后在异步线程或远程调用中突然暴雷 - 部分框架（如 Spring WebFlux 的错误处理链）对 checked 异常和 unchecked 异常的传播策略不同，但序列化行为一致
- 如果你重写了
writeObject或readObject，务必调用defaultWriteObject()/defaultReadObject()，否则父类字段（如message、cause）不会被序列化
最常被忽略的一点：异常的 cause 字段（即 initCause() 设置的嵌套异常）也必须可序列化，否则整个链路序列化失败——哪怕你的自定义异常本身没问题。
