是的，transient 修饰的字段反序列化后一定是默认值，jvm 直接跳过该字段并用其类型默认值填充（如 int→0、string→null），且 final transient 字段也不会恢复原值。
transient 修饰的字段在反序列化后一定是默认值吗
是的，只要字段被 transient 修饰，且类实现了 Serializable，它就不会写入序列化流；反序列化时 JVM 直接跳过该字段，用其类型的默认值填充（int → 0，String → null，对象引用 → null）。
- 这个行为和是否被
static修饰无关——static字段本就不参与序列化，加transient是冗余的 -
final transient字段是个特例：反序列化后仍是默认值，不会恢复原值（哪怕构造时已赋值），因为 JVM 不会为transient字段执行任何赋值逻辑 - 如果需要自定义反序列化逻辑（比如从其他字段推算出该值），得重写
readObject方法，否则它永远“失联”
哪些场景下必须用 transient 而不是删掉字段
不是所有“不想序列化”的字段都能靠删掉来解决——有些字段必须存在，只是不该落盘或传网。
- 敏感数据：如
password、token、apiKey，删掉会导致业务逻辑断裂，加transient才是安全又可用的做法 - 不可序列化类型：比如字段是
InputStream、Thread、Socket等未实现Serializable的类，不加transient会直接抛NotSerializableException - 循环引用破环：A 持有 B，B 又持有 A，不把其中一端标为
transient，默认序列化会栈溢出 - 临时状态缓存：如
cacheResult、isDirty，只在当前 JVM 生命周期有效，序列化后反而造成语义错乱
transient 和自定义序列化方法（writeObject/readObject）怎么配合
单独用 transient 只能“丢弃”，但有时你希望“换种方式存”。这时候得手动控制序列化流程。
- 必须把
writeObject和readObject声明为private void，且参数固定为ObjectOutputStream/ObjectInputStream - 在
writeObject中，先调用defaultWriteObject()序列化非transient字段，再手动 write 那些你想保留逻辑的transient字段（比如加密后存） - 对应地，
readObject里先defaultReadObject()，再手动 read 并还原 —— 否则那些字段仍为默认值 - 漏掉
defaultWriteObject()或defaultReadObject()会导致非transient字段也丢失，这是高频翻车点
为什么加了 transient 还报 NotSerializableException
常见于字段类型本身不可序列化，但你只加了 transient，却忘了检查它的“上游依赖”。
立即学习“Java免费学习笔记（深入）”；
- 比如字段是
private MyService service;，而MyService没实现Serializable—— 加transient就能过 - 但如果字段是
private List<connection> connections;</connection>，而Connection不可序列化，即使connections加了transient，若你在writeObject里手动写了它（比如误调用了out.writeObject(connections)），照样崩 - 另一个隐蔽坑：使用 Lombok 的
@Data或@AllArgsConstructor时，它会自动生成serialVersionUID但不会帮你加transient，容易误以为“类可序列化=所有字段都安全”
transient 看似简单，真正麻烦的是它不报错、不警告，只在反序列化后悄悄变成 null 或 0，等业务逻辑某处 NPE 或数值异常才暴露——所以凡是涉及 RPC、缓存、本地持久化的 Java 对象，每个字段都得问一句：它该活到下一次 JVM 启动吗？ 
