原型模式在Java中依赖克隆机制，深克隆与浅克隆的底层差异直接决定对象隔离性是否可靠：浅克隆仅复制引用地址导致嵌套对象共享；手动深克隆需逐层实现且易出错；序列化深克隆受限于Serializable约束、构造器绕过及性能问题；Cloneable接口无强制契约，易引发异常或语义不符。
原型模式在Java中依赖克隆机制，而深克隆与浅克隆的底层实现差异，直接决定了对象隔离性是否可靠——这不是语法问题，而是内存模型和JVM行为引发的真实陷阱。
浅克隆的“假独立”：引用共享不可见
Object.clone() 是 native 方法，执行的是内存块级按位复制。它只复制字段值：基本类型值被完整拷贝；但对引用类型，仅复制地址（即指针），新旧对象指向同一堆内存中的实例。这种共享在代码中毫无提示，修改嵌套对象时“意外联动”就发生了。
- 比如 Person 持有 Address 引用，浅克隆后 p1 和 p2 的 address 字段指向同一个 Address 实例
- p2.address.city = "Shanghai" → p1.address.city 同步变更为 Shanghai
- 问题根源不在代码逻辑，而在 clone() 不处理引用层级，且无编译期或运行期警告
深克隆的“手动陷阱”：递归责任全在开发者
标准 clone() 不提供深克隆能力。若手动实现，必须显式克隆每个引用字段——这要求每个嵌套类也支持克隆，且需逐层调用 clone()。一旦某一层遗漏、未实现 Cloneable、或 clone() 方法未正确重写，整个链路就退化为浅克隆。
- 例如 User.deepClone() 中复制 hobbies 列表，但若 hobbies 元素本身是自定义对象，且未对其 clone，仍存在共享
- 若嵌套对象来自第三方库（如 Jackson 的 JsonNode），无法修改其源码，手动深克隆路径即中断
- 递归 clone 容易引发 StackOverflowError（循环引用未检测）或 NullPointerException（字段为 null 未判空）
序列化深克隆的隐性代价：可序列化 ≠ 安全深克隆
借助 ObjectOutputStream / ObjectInputStream 实现深克隆看似通用，但它引入三类底层陷阱：
立即学习“Java免费学习笔记（深入）”；
- Serializable 约束强制：所有嵌套对象及其字段类型都必须可序列化，transient 字段被跳过，可能丢失关键状态
- 构造函数绕过副作用：反序列化不调用任何构造方法或初始化块，依赖默认构造器 + 反序列化逻辑，若类依赖构造器中注册监听、分配资源等，克隆体将缺失这些行为
- 性能与兼容性风险：序列化涉及字节流编解码，比内存拷贝慢一个数量级；Java 版本升级可能导致 serialVersionUID 不匹配，抛出 InvalidClassException
Cloneable 接口的契约断裂：标记接口无强制约束
Cloneable 是空接口，仅起运行时标记作用。它不声明 clone() 方法，也不强制子类重写——导致大量误用：
- 未实现 Cloneable 却调用 super.clone() → 抛 CloneNotSupportedException，但异常常被吞掉或忽略
- 实现了 Cloneable 却未重写 clone() → 编译通过，运行时仍调用 Object 默认实现（浅克隆），语义与预期不符
- clone() 方法访问权限为 protected，子类若未显式改为 public，外部无法调用，原型模式 Client 角色无法使用
