java序列化核心陷阱在于“序列化后是否仍是原对象”，需分场景明确工具链并守边界：transient仅对jdk原生有效；防json泄露用@jsonignore等；防日志泄露重写tostring()并清空char[]；避免getter引发幽灵属性；必须显式声明serialversionuid；单例需readresolve()或用枚举。
Java对象序列化看似简单，但一不留神就掉坑里。核心问题不在“能不能序列化”，而在“序列化后还是不是原来的它”。避开陷阱的关键是分清场景、明确工具链、守住边界。
别把transient当万能盾牌
transient只对JDK原生序列化（ObjectOutputStream/ObjectInputStream）生效，对JSON、日志、数据库、HTTP响应完全无效。加了transient，密码照样出现在Spring Boot的JSON返回里——因为Jackson根本不看它。
- 防JSON泄露：用
@JsonIgnore（Jackson）、@JSONField(serialize = false)（Fastjson）或GsonBuilder().excludeFieldsWithModifiers(Modifier.TRANSIENT) - 防日志/内存泄露：重写
toString()跳过敏感字段；敏感内容优先用char[]，用完立即Arrays.fill(pwd, '\0') - 别依赖transient做安全隔离：网络层用DTO分离，存储层用加密字段，不要把User实体直接扔给前端
小心getter/setter引发的“幽灵属性”
Fastjson、Jackson等框架会扫描所有getXXX/isXXX方法，按JavaBean规范推导属性名。哪怕你只写了个getUserName()计算方法，没有userName字段，框架也会试图反序列化userName并报set property error。
- 命名避坑：避免无对应字段的getXXX方法；若必须存在，加
@JsonIgnore或@JSONField(serialize = false) - 升级Fastjson时特别注意：1.2.54+版本对getter异常更敏感，测试阶段要覆盖所有getter逻辑
- 统一序列化入口：避免混用ObjectOutputStream、Jackson、Fastjson处理同一类对象
版本兼容性不能靠运气
serialVersionUID不是可有可无的装饰。没显式声明时，JVM根据类结构自动生成；一旦字段增删、类型变更、甚至IDE自动重排代码，这个值就变了，反序列化直接抛InvalidClassException。
- 每个实现
Serializable的类，第一行就该写：private static final long serialVersionUID = 1L; - 类结构变更时，手动递增版本号（如从1L→2L），而非依赖自动生成
- Redis等跨服务缓存场景，上下游服务必须使用相同序列化方式和类版本，否则字节流一进一出就变“薛定谔的对象”
别让单例在反序列化里“克隆”自己
默认反序列化会绕过私有构造函数，新建一个实例，破坏单例语义。比如饿汉式单例被反序列化两次，就变成两个对象。
- 在单例类中添加
readResolve()方法，强制返回原有实例：
private Object readResolve() { return INSTANCE; }
- 如果用枚举实现单例（
public enum Singleton { INSTANCE; }），天然免疫反序列化破坏，无需额外处理 - 分布式系统中，单例仅限本JVM有效；跨节点需用Redis锁、ZooKeeper等协调，不能靠序列化保证
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
