transient 字段反序列化时为 null 是因 JVM 跳过其序列化，属设计行为；未声明 serialVersionUID 会导致类结构变更后反序列化失败；推荐手动设为 1L 并谨慎升级；JSON、protobuf 等是更安全可靠的替代方案。
为什么反序列化时 transient 字段总是 null
因为 transient 的语义就是“不参与序列化”，JVM 在写入字节流时直接跳过它，反序列化自然无法恢复。这不是 bug，是设计行为。
- 仅对实例变量生效，
static字段本就不序列化，加transient无意义 - 若字段类型本身不可序列化（如
Thread、Socket），必须加transient，否则抛NotSerializableException - 想在反序列化后自动初始化该字段？重写
readObject方法，在里面赋值，别指望 JVM 自动填
serialVersionUID 不写会怎样
不显式声明 serialVersionUID，JVM 会按类结构自动生成一个；但只要类稍有改动（比如加个字段、改个访问修饰符），生成的值就变，导致反序列化失败：抛 InvalidClassException，提示 “local class incompatible”。
- 线上服务升级时，老数据文件或缓存对象很可能因
serialVersionUID不匹配而无法加载 - 建议始终用
private static final long serialVersionUID = 1L;起手，后续兼容性变更（如新增transient字段）不改它；破坏性变更再升版本号 - IDE（如 IntelliJ）可自动生成基于当前类结构的哈希值，但不如手动设为
1L来得可控
自定义序列化逻辑：什么时候必须重写 writeObject 和 readObject
当默认机制无法满足需求时才动手——比如字段加密、敏感信息过滤、父类字段补全、或兼容旧版本数据格式。
- 这两个方法必须是
private void writeObject(ObjectOutputStream out)和private void readObject(ObjectInputStream in)，签名错一个字符就无效 - 务必在第一行调用
defaultWriteObject()或defaultReadObject()，否则非transient字段全丢 - 如果类继承自不可序列化的父类，且父类有状态字段，必须在
readObject中手动重建父类状态（通过反射或构造器）
替代 Serializable 的更可靠方案有哪些
Java 原生序列化脆弱、慢、不跨语言、有安全风险（反序列化 gadget 攻击），生产环境应优先考虑替代方案。
立即学习“Java免费学习笔记（深入）”；
-
JSON（用jackson或Gson）：人眼可读、跨语言、字段增删兼容性好，但丢失类型信息和 final 字段语义 -
Protocol Buffers（protobuf）：体积小、速度快、强契约，需预定义.proto文件，适合微服务间通信 - 完全避免序列化：用数据库主键代替对象直传，或用 DTO + 显式构造，把“序列化”这个隐式过程变成可测试、可审计的显式转换
真正麻烦的从来不是怎么序列化，而是怎么让旧数据在新代码里活下来——这点上，任何二进制序列化都比不上带版本字段的 JSON。
