Java对象序列化依赖java.io.Serializable标记接口，JVM通过ObjectOutputStream.writeObject()检查该接口并默认序列化非transient非static字段；需显式声明serialVersionUID保障版本兼容，transient和static字段因安全或语义原因不参与默认序列化；现代项目更推荐JSON、Protobuf等跨语言方案。
Java 中的对象序列化不是靠实现 JavaSerializable 接口——这个接口根本不存在。真正起作用的是 java.io.Serializable，它是一个空的标记接口（marker interface），不定义任何方法。
为什么实现 Serializable 就能序列化？
JVM 在执行 ObjectOutputStream.writeObject() 时，会检查对象所属类是否实现了 Serializable 接口。如果没有，直接抛出 NotSerializableException；如果实现了，JVM 就按默认规则把对象字段（非 transient、非 static）写入字节流。
- 它不提供任何方法让你“控制”序列化逻辑——除非你手动添加
writeObject()和readObject()这两个私有方法 - 实现该接口只是“开绿灯”，不代表自动支持跨版本兼容或安全反序列化
-
serialVersionUID字段不是必须的，但强烈建议显式声明，否则编译器自动生成的值极易因类结构微调而变化，导致反序列化失败
常见错误：反序列化时抛出 InvalidClassException
典型错误信息：java.io.InvalidClassException: MyClass; local class incompatible: stream classdesc serialVersionUID = 123, local class serialVersionUID = 456
- 根本原因是序列化时和反序列化时的
serialVersionUID不一致 - 没声明
serialVersionUID时，JVM 根据类名、接口、字段、方法等生成一个哈希值，哪怕加了个注释或改了方法顺序，都可能变 - 修复方式：在类中加上
private static final long serialVersionUID = 1L;（数值可自定义，但同版本必须一致） - 如果已有线上数据且无法修改旧序列化字节流，升级类时应复用旧的
serialVersionUID值
transient 和 static 字段为什么不会被序列化？
因为序列化的目标是“对象状态的持久化表示”，而：
-
transient明确告诉 JVM：“这个字段我不希望进字节流”，比如密码、缓存、数据库连接等敏感或临时数据 -
static属于类而非实例，不属于某个对象的状态，自然不参与单个对象的序列化 - 注意：若你重写了
writeObject()方法，仍可以手动写入transient字段——这属于主动绕过默认行为，需同步在readObject()中恢复
private void writeObject(ObjectOutputStream out) throws IOException {
out.defaultWriteObject(); // 先调用默认序列化
out.writeLong(System.currentTimeMillis()); // 手动追加时间戳（哪怕它是 transient）
}
替代方案比 Serializable 更实用？
纯 Java 原生序列化已基本不推荐用于网络传输或长期存储：
- 与语言强绑定，无法被 Python/Go 等解析
- 存在严重安全风险：反序列化任意字节流可能触发远程代码执行（如 Apache Commons Collections 反序列化漏洞）
- 性能差、体积大、无向后/向前兼容保障
- 现代项目更倾向用 JSON（
jackson-databind）、Protobuf（protobuf-java）或 Avro，它们明确分离 schema 与数据，支持跨语言、版本演进和校验
只有在极少数场景下才用 Serializable：比如同一 JVM 内部的短生命周期缓存（ConcurrentHashMap 的 value）、某些框架内部通信（如 RMI 的参数传递，但 RMI 本身也已过时）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
