不是必须但强烈建议显式声明；因Exception实现Serializable，未声明时JVM自动生成serialVersionUID，类结构变更会导致反序列化失败，如RMI、Dubbo等跨JVM场景。
自定义异常类必须显式声明 serialVersionUID 吗？
不是必须，但强烈建议显式声明。Java 的 Exception 类本身实现了 Serializable，因此所有自定义异常默认可序列化；JVM 会为未声明 serialVersionUID 的类自动生成一个（基于类名、接口、方法签名等计算）。一旦类结构变更（比如新增字段、修改访问修饰符），自动生成的值就会变化，导致反序列化时抛出 InvalidClassException。
什么情况下不写 serialVersionUID 会出问题？
常见于以下场景：
- 异常对象被写入文件或通过网络传给另一 JVM（如 RMI、Dubbo、Spring Cloud Feign fallback 中 throw 的异常）
- 使用了 Java 原生序列化（
ObjectOutputStream/ObjectInputStream）持久化异常实例 - 框架内部捕获并序列化异常后跨节点传递（例如某些消息队列消费者重试时携带原始异常）
此时若服务端升级了异常类（比如加了一个 private String errorCode; 字段），而客户端仍用旧版类反序列化，就会失败。
怎么写才安全？
推荐写法是显式指定一个固定长整型值，并保持长期不变：
立即学习“Java免费学习笔记（深入）”；
public class BusinessException extends Exception {
private static final long serialVersionUID = 1L; // 简单明确，够用
private final String code;
public BusinessException(String message, String code) {
super(message);
this.code = code;
}
}
注意事项：
- 值用
1L或123456789L都可以，关键是「不随代码改动而变」 - 如果确实需要版本演进（极少见），可手动递增，但需同步更新所有上下游依赖方
- IDE（如 IntelliJ）通常会提示「Missing
serialVersionUID」，别直接忽略或用「AddserialVersionUID」快捷修复——它生成的是计算值，和手写1L效果不同
不实现 Serializable 能绕过这个问题吗？
不能，也不该这么做。因为：
-
Exception父类已实现Serializable，子类无法“取消”该实现 - 即使你加
private void writeObject(ObjectOutputStream out) throws NotSerializableException强制阻止序列化，多数框架（如 Spring、Logback）在日志或传播过程中仍可能尝试序列化异常，结果是运行时报错 - 放弃序列化支持，等于主动放弃分布式调试、异常透传、审计日志落地等关键能力
真正该控制的，是异常是否应该被序列化传播，而不是靠删 serialVersionUID 来“假装不可序列化”。
