序列化代理模式通过writeReplace()和readResolve()控制序列化流向，强制反序列化经构造函数校验，杜绝反射绕过风险。代理类为static final字段私有嵌套类，仅保存核心状态，不持真实对象引用，专用于防御反序列化漏洞。
Java 序列化代理模式（Serialization Proxy Pattern）是一种主动放弃直接序列化原始类，转而序列化一个专用代理对象的设计方式。它的核心价值不是让序列化“更方便”，而是让反序列化过程可控、可校验、可防御——尤其针对反序列化漏洞这一长期高危风险。
为什么需要序列化代理？
默认的 Java 反序列化机制存在根本性安全缺陷：它绕过构造函数和访问控制，直接通过反射创建对象实例。攻击者只要能控制输入字节流，就可能触发任意类的初始化逻辑，甚至执行恶意代码。序列化代理把反序列化入口收归代理类，所有真实对象都必须经过构造函数创建，天然强制执行业务约束（比如参数校验、状态合法性检查）。
怎么实现一个可靠的序列化代理？
关键在于两个钩子方法：writeReplace() 和 readResolve()，它们不是装饰性功能，而是控制序列化/反序列化流向的开关：
-
在主类中定义
writeReplace()：该方法在序列化前被调用，返回一个代理对象（如DogProxy），后续实际写入流的是这个代理对象，而非原始类实例 -
在代理类中实现
readResolve()：该方法在反序列化完成后被调用，负责用代理中保存的数据，通过正常构造函数创建并返回主类新实例 -
主类不声明
serialVersionUID或设为private：避免被意外反序列化；代理类则需显式声明自己的serialVersionUID，用于版本管理 - 代理类字段与主类核心状态严格对齐：只保留必要、可序列化的字段；敏感字段（如密码）、临时状态、非 Serializable 引用等一律不进入代理
代理类要怎么设计才真正安全？
代理类不是简单的 DTO，它承担着“可信中间人”的角色：
立即学习“Java免费学习笔记（深入）”；
-
代理类必须是
static内部类或独立顶层类，避免持有外部类引用导致内存泄漏或意外状态泄露 -
代理类构造器应做最小化数据提取，不执行复杂逻辑；
readResolve()中才做完整校验（例如年龄是否在 0–100 范围内） -
代理类字段全部设为
private final，杜绝反序列化后被篡改；如果字段本身不可序列化，需确保代理类仍能安全重建主类 -
避免在代理类中暴露任何可被利用的
readObject、writeObject方法，除非有明确压缩/加密需求且已充分审计
它和普通代理模式有什么本质区别？
这不是为了“增强功能”或“延迟加载”的结构型代理，而是专为序列化生命周期定制的防御型代理：
- 普通代理关注运行时行为拦截（如日志、权限），序列化代理只在序列化/反序列化两个瞬间起作用
- 普通代理通常持有真实对象引用，序列化代理只持有重建所需的数据快照，不持有主类实例
- 普通代理可动态生成（如 JDK 动态代理），序列化代理必须是编译期确定的、类型安全的静态类
