Java异常类默认实现Serializable接口，以支持RMI、分布式框架异常传递及日志快照等场景；自定义异常继承Exception或RuntimeException时无需显式实现，但需注意字段可序列化并建议声明serialVersionUID。
Java 中的异常类默认需要实现 Serializable 接口，这是为了支持异常对象在网络传输或持久化场景下的正确序列化与反序列化。
为什么异常类要实现 Serializable
Java 异常类（如 Exception、RuntimeException 及其子类）都直接或间接继承自 Throwable，而 Throwable 类本身已实现了 Serializable 接口。这意味着所有标准异常类天然可序列化。
这一设计主要服务于以下场景：
- 远程方法调用（RMI）中，服务端抛出的异常需传回客户端，必须能被序列化
- 分布式框架（如 Dubbo、gRPC-Java 封装层）在跨进程传递异常时依赖序列化机制
- 日志系统或监控组件对异常做快照保存（如写入文件、消息队列）时需要序列化能力
自定义异常类是否必须显式实现 Serializable
如果自定义异常继承自 Exception 或 RuntimeException，无需显式声明 implements Serializable —— 因为父类已实现。但有两点关键注意事项：
立即学习“Java免费学习笔记（深入）”；
- 若在异常类中添加了**非静态、非瞬态（non-transient）的实例字段**，且该字段类型不可序列化，则反序列化会失败；此时应确保字段可序列化，或标记为
transient - 建议显式声明
private static final long serialVersionUID = 1L;，避免因类结构变化导致反序列化失败（尤其是跨版本通信时）
不实现 Serializable 的后果
若强行让异常类不实现 Serializable（例如通过继承 Throwable 但不实现接口），会导致：
- 编译通过，但运行时抛出
NotSerializableException（当尝试序列化该异常时） - RMI 调用直接中断，客户端收不到有效错误信息
- 某些 AOP 框架（如 Spring AOP 在远程代理场景）无法正确传播异常
最佳实践建议
对于自定义异常，推荐按以下方式编写：
- 继承
Exception或合适的标准异常基类（而非裸写Throwable） - 添加
serialVersionUID字段，值可使用 IDE 自动生成或固定值（如1L） - 避免在异常中持有不可序列化的资源（如
Thread、Socket、Connection等），必要时用transient修饰 - 若异常仅用于本地逻辑且明确不会跨 JVM 传递，技术上可不关心序列化，但保持默认兼容性仍是更稳妥的选择
不复杂但容易忽略。只要遵循标准继承路径，Java 异常的序列化支持是开箱即用的。
