Java原生序列化不处理循环引用致StackOverflowError，需用XStream/FST/Kryo等支持引用的库；transient字段反序列化后为null因未初始化；serialVersionUID不一致引发InvalidClassException，应显式声明并按变更规则更新；Jackson默认不识别transient且需注解或配置支持循环引用与对象同一性。
Java序列化遇到StackOverflowError：循环引用怎么破
Java原生序列化（ObjectOutputStream）默认不处理对象图中的循环引用，一旦两个对象互相持有对方引用（比如Parent持Child，Child又回持Parent），序列化时会无限递归，最终抛出StackOverflowError。
这不是bug，是设计如此——它不做图遍历，只做深度优先遍历且无访问标记。解决办法不是“绕开”，而是让JVM知道“这个对象我见过”：
- 确保所有参与序列化的类都实现
Serializable接口（否则直接NotSerializableException） - 在自定义
writeObject/readObject方法中手动控制引用写入逻辑（较重，仅限极少数场景） - 更现实的做法：换用支持循环引用的序列化库，如
XStream（默认开启allowTypes和引用解析）、FST或Kryo（需显式启用setReferences(true)）
transient字段在反序列化后为什么还是null？
transient关键字的作用很干净：告诉ObjectOutputStream“别管这个字段”，跳过其序列化过程。但它**不负责初始化**，所以反序列化后该字段值就是类型默认值（对象为null，int为0，boolean为false）。
常见误解是以为transient能触发某种“懒加载”或“自动重建”。其实它只是单向屏蔽：
立即学习“Java免费学习笔记（深入）”；
- 序列化时：跳过
transient字段，不写入字节流 - 反序列化时：不从流中读取，也不调用任何构造器或setter去恢复它
- 如果需要重建，必须在
readObject方法里手动赋值，例如：this.cache = new HashMap();
serialVersionUID不一致导致InvalidClassException怎么办
当类结构变更（比如加了字段、改了方法签名）后，若没显式声明serialVersionUID，JVM会基于类名、接口、字段、方法等自动生成一个。只要任一细节变动，生成的UID就不同，反序列化时立即报InvalidClassException: class invalid for deserialization。
这不是校验失败，是JVM在拒绝“可能语义错乱”的兼容尝试：
- 给类加上
private static final long serialVersionUID = 1L;（初始值任意，但后续修改需同步更新） - 字段增删属于“兼容变更”，可保留旧UID；但字段类型变更、删除
Serializable父类、改static/final语义等，通常应提升UID值 - 生产环境建议用
serialver命令行工具生成稳定UID：serialver com.example.MyClass
为什么Jackson不认transient，却能序列化循环引用？
Jackson不是Java原生序列化，它走的是POJO反射+树模型/流模型路径，行为规则完全不同：
transient对Jackson默认无效——它只看getter/setter或字段可见性（除非配置MapperFeature.PROPAGATE_TRANSIENT_MARKER）。而循环引用，默认会报JsonMappingException: Direct self-reference，但可通过注解解决：
- 用
@JsonManagedReference+@JsonBackReference配对处理父子关系 - 或全局启用引用处理：
objectMapper.configure(SerializationFeature.FAIL_ON_SELF_REFERENCES, false)，再配合SimpleModule注册StdSerializerProvider支持引用 - 注意：开启引用后JSON会多出
@id和@ref字段，前端需适配
真正容易被忽略的是：同一个对象在不同字段中多次出现（非循环，而是共享引用），Java原生序列化能正确还原引用关系，而Jackson默认会重复序列化——得靠@JsonIdentityInfo才能保持对象同一性。
