Java序列化是将对象转为字节流以持久化或传输，反序列化则还原对象；必须实现Serializable接口（空标记接口），否则抛NotSerializableException，且需显式声明serialVersionUID保障版本兼容。
Java序列化就是把内存里的对象“压成字节流”，让它能存进文件、数据库，或通过网络发给另一台机器；反序列化则是把这串字节流“还原回原样”。它不是魔法，而是一套有明确规则、也容易踩坑的持久化机制。
为什么必须实现 Serializable 接口？
这个接口是纯标记用的——没方法、不强制你写任何逻辑，但它像一张“通行证”：JVM只对实现了它的类允许调用 ObjectOutputStream.writeObject()。没实现？运行时直接抛 NotSerializableException。
- 它不参与继承链自动传递：父类没实现
Serializable，子类即使实现了，反序列化时也会因父类无默认构造器而失败 - 接口本身不保证字段可序列化：如果某个成员变量类型（比如自定义类）不可序列化，又没加
transient，照样报错 - 它不等于“安全”：序列化数据可被篡改、反序列化可能触发恶意代码（尤其配合 gadget 链），生产环境慎用原生序列化传敏感数据
serialVersionUID 不写会怎样？
不显式声明 private static final long serialVersionUID，JVM 会按类名、接口、字段等生成一个哈希值。但只要类结构稍有变动（比如加个字段、改个访问修饰符），这个值就变——导致反序列化时抛 InvalidClassException：“无法匹配序列化版本”。
- 建议始终手动指定，例如：
private static final long serialVersionUID = 1L; - 升级兼容性靠它：大版本重构时可主动递增该值，避免旧数据彻底失效
- IDE（如 IntelliJ）通常能一键生成基于当前结构的稳定值，比
1L更稳妥
哪些东西不会被序列化？常见陷阱清单
序列化只保存对象“实例状态”，不是整个 JVM 快照。以下内容一律丢弃：
-
static字段：属于类，不属于对象实例 -
transient字段：显式声明“别存我”，反序列化后为null或0 - 未实现
Serializable的成员对象：除非你重写writeObject()手动处理 - 构造器、方法、内部类引用（非静态内部类自带外部类引用，若外部类不可序列化则连带失败）
典型翻车场景：ArrayList 可序列化，但如果你存了个 Thread 或 Socket 进去——它们没实现 Serializable，一序列化就崩。
用 ObjectOutputStream 和 ObjectInputStream 的实操要点
这是最基础、也最容易误用的一组 API。关键不在“会不会写
”，而在“边界怎么控”：
- 务必用
try-with-resources：ObjectOutputStream内部有缓冲，不close()可能导致字节流截断，反序列化读到一半就EOFException - 反序列化必须捕获
ClassNotFoundException：字节流里只存了类名，运行时若 classpath 缺失该类，直接炸 - 不要长期依赖二进制格式：不同 JDK 版本间可能存在兼容性波动；跨语言系统（如 Go/Python 调用 Java 服务）基本无法解析原生序列化流
try (FileOutputStream fos = new FileOutputStream("user.ser");
ObjectOutputStream oos = new ObjectOutputStream(fos)) {
oos.writeObject(new User("李四", 28));
} catch (IOException e) {
// 注意：这里不处理 ClassNotFoundException，因为 write 不抛它
e.printStackTrace();
}
真正难的从来不是“怎么序列化”，而是想清楚：这个对象是否真的需要被序列化？它的生命周期、安全性、跨版本兼容性、上下游系统支持度，都得在加 implements Serializable 那一刻就想明白。否则，一个 serialVersionUID 写错，或一个 transient 忘加，就可能让线上恢复流程卡死几小时。
