不是必须但强烈建议显式声明；因Exception实现Serializable，JVM会自动生成易变的serialVersionUID，导致反序列化失败，故所有可序列化的自定义异常都应显式定义private static final long serialVersionUID = 1L;
自定义异常类必须显式声明 serialVersionUID 吗？
不是必须，但强烈建议显式声明。Java 的 Exception 类本身实现了 Serializable，因此所有自定义异常默认可序列化；JVM 会自动生成一个默认 serialVersionUID，但它基于类名、接口、字段、方法签名等计算得出，极易因代码微调（比如加个 private 字段、改个方法注释）而改变——一旦序列化数据（如日志、远程调用抛出的异常对象）被反序列化时版本不匹配，就会抛出 InvalidClassException。
实操建议：
- 所有实现
Serializable的异常类（即继承Exception或其子类），都应显式定义private static final long serialVersionUID = 1L;（或更语义化的值，如1001L） - 若异常只在本地 throw/catch、不跨 JVM 传递或持久化，可暂不处理，但团队协作或框架集成（如 Spring RPC、Dubbo、Logback 异常序列化）时风险极高
- IDE（如 IntelliJ）通常会警告“The serializable class X does not declare a static final serialVersionUID field”，别忽略它
serialVersionUID 值写多少才安全？
只要保证同一类在不同编译版本中值不变即可，和具体数字无关。常用做法是：
- 初始版本统一用
1L—— 简单、明确、无歧义 - 当类结构发生**兼容性变更**（如新增
transient字段、增加私有辅助方法）时，serialVersionUID不必更新 - 当发生**不兼容变更**（如删字段、改字段类型、把
public方法改成private）且需保留旧序列化数据兼容性时，才需手动升级该值（如从1L改为2L） - 避免用 IDE 自动生成的长哈希值（如
-1234567890123456789L），它本质仍是默认策略，起不到稳定控制作用
RuntimeException 子类是否也要加 serialVersionUID？
要看使用场景。虽然 RuntimeException 及其子类（如 IllegalArgumentException）通常不被序列化，但只要你自定义了一个运行时异常，并且它可能出现在以下情况中，就必须加：
立即学习“Java免费学习笔记（深入）”；
- 被远程服务（如 gRPC、Spring Cloud OpenFeign）作为错误响应体传输
- 被写入支持序列化的日志系统（如 Log4j2 的
SerializedLayout） - 被
ObjectOutputStream手动序列化（例如缓存异常快照） - 父类已实现
Serializable（如继承了Exception），子类即使不重写任何东西，也继承了可序列化性
换句话说：是否加 serialVersionUID，不取决于“是不是 RuntimeException”，而取决于“这个类实例有没有可能被序列化”。
不加 serialVersionUID 的真实报错什么样？
典型错误信息如下：
java.io.InvalidClassException: com.example.MyBizException; local class incompatible: stream classdesc serialVersionUID = 123456789, local class serialVersionUID = 987654321
这种问题往往在线上环境突然出现：旧版本服务抛出异常 → 消息被 Kafka 持久化 → 新版本消费者启动后反序列化失败 → 整个消费线程卡死或跳过消息。排查时容易误判为网络或配置问题，实际根源就是那个没写 serialVersionUID 的异常类被悄悄重新编译了。
最易被忽略的一点：模块拆分后，异常类若同时被多个 module 引用，各 module 单独编译时生成的默认 serialVersionUID 极可能不一致——哪怕源码完全一样。
