transient修饰的字段反序列化后为null或默认值，因其不参与序列化过程；需在readObject中手动重建或通过getter惰性计算，且仅适用于实例变量，不能用于静态字段等。
transient 修饰的字段在反序列化后值为 null 或默认值
被 transient 修饰的实例变量不会写入序列化流，因此反序列化时 JVM 不会恢复它——它保持初始化时的值（引用类型为 null，基本类型为对应默认值，如 int 是 0，boolean 是 false）。这不是 bug，是设计行为。
常见错误现象：反序列化后发现某个字段突然变成 null，但代码里明明赋过值。没检查是否误加了 transient，或忘了在 readObject 中手动重建。
- 只对实例变量生效，不能修饰静态字段、局部变量、方法或类
- 即使字段类型本身可序列化（比如
String），加了transient就不存 - 若字段是对象引用且该类未实现
Serializable，不加transient会直接抛NotSerializableException
临时计算字段用 transient + 自动重建更安全
像总价、缓存结果、缩略图这些能从其他字段推导出来的值，适合用 transient 排除序列化，再配合自定义反序列逻辑重建，避免数据不一致。
例如一个购物车类有 items 和 transient double total，反序列化后 total 是 0，但 getter 可以按需重算：
public double getTotal() {
if (total == 0 && !items.isEmpty()) {
total = items.stream().mapToDouble(Item::getPrice).sum();
}
return total;
}
更严谨的做法是在 readObject 中显式重建：
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
in.defaultReadObject(); // 先读其他字段
this.total = items.stream().mapToDouble(Item::getPrice).sum(); // 再补算
}
- 别依赖构造器或 init 方法来初始化
transient字段——反序列化不调用构造器 - 如果重建逻辑耗时或依赖外部资源（如 DB、网络），要考虑是否真该序列化整个对象
-
readObject必须是 private、参数和异常签名严格匹配，否则会被忽略
敏感字段必须用 transient，但仅靠它不够
密码、token、密钥等字段加 transient 是基础操作，但它只防序列化环节泄露。实际中还需注意：
- 内存中仍存在明文，可能被 heap dump 抓取；建议配合
char[]+ 显式清空 - JSON 序列化（如 Jackson/Gson）默认不识别
transient，需额外配置注解（如@JsonIgnore） - 若用了 Lombok 的
@Data，记得排除transient字段的 setter/getter，否则可能意外暴露
transient 不解决循环引用，但能辅助破环
两个对象互相持有对方引用（A → B，B → A），默认序列化会栈溢出。这时把其中一端标为 transient 是常用手段，但要注意语义是否合理。
比如订单（Order）持有一个用户（User），而 User 又持有一组订单列表。通常应把 User.orders 设为 transient，因为订单里已有 userId，反序列化时可通过 ID 查库重建关系，而非硬塞回引用。
- 不要为了“能序列化”而随意加
transient，先评估业务上是否真需要双向引用持久化 - 若必须保留双向关系，考虑用
writeObject/readObject手动控制序列化流程 - 使用 IDE 检查
serialVersionUID是否一致，否则反序列化会抛InvalidClassException
容易被忽略的一点：transient 字段的初始值在反序列化后不会被重置为声明时的值（比如 private transient String cache = "init";），它始终是 null。想控制初始状态，只能靠 readObject 或 getter 里的惰性逻辑。
