super.clone() 默认只做浅拷贝，无法实现深拷贝；需先调用 super.clone() 获取浅拷贝，再手动克隆所有可变引用字段，且每层子类 clone() 必须显式处理自身字段。
super.clone() 为什么不能直接用于深拷贝
super.clone() 默认只做浅拷贝：它会复制对象本身，但所有引用类型的字段仍指向原对象中的同一块内存。如果你的类包含 ArrayList、StringBuffer、自定义对象等引用字段，直接返回 super.clone() 的结果，修改副本里的集合或子对象，会意外影响原对象。
常见错误现象：CloneNotSupportedException 没抛出，程序也不报错，但业务逻辑出 bug —— 比如两个“独立”的配置实例共享同一个 Map，改一个，另一个也变了。
- 必须确保当前类实现
Cloneable接口（否则super.clone()抛CloneNotSupportedException） -
clone()方法必须声明为public，因为Object.clone()是protected - 不能依赖
super.clone()自动处理嵌套对象，那是你自己的责任
如何在 clone() 中安全调用 super.clone() 并补全深拷贝
正确做法是：先调用 super.clone() 得到浅拷贝实例，再对每个可变引用字段手动克隆或重建。关键在于“谁负责克隆谁”——只有你自己最清楚哪些字段需要深拷，哪些可以共享（比如 String 是不可变的，无需克隆）。
示例场景：一个含 name（String）、items（ArrayList<item></item>）、config（自定义 Config 类）的类：
立即学习“Java免费学习笔记（深入）”；
public class Order implements Cloneable {
private String name;
private ArrayList<Item> items;
private Config config;
@Override
public Order clone() {
try {
Order cloned = (Order) super.clone(); // 浅拷贝完成
cloned.items = new ArrayList<>(this.items); // ArrayList 构造器创建新列表（但 Item 仍是浅拷）
cloned.config = this.config.clone(); // 要求 Config 也实现 Cloneable + 正确 clone()
return cloned;
} catch (CloneNotSupportedException e) {
throw new AssertionError(e); // Object 实现了 Cloneable，这里不应发生
}
}
}
-
ArrayList的构造器传入另一个Collection，会新建底层数组并复制引用 —— 这仍是浅的；若Item可变，还需遍历cloned.items对每个Item调用clone() - 如果
Config没重写clone()或没实现Cloneable，这行会抛异常或返回浅拷贝 - 注意字段顺序：必须先
super.clone()，再赋值新对象，否则可能因字段未初始化导致 NPE
继承链中多个 clone() 方法怎么协作才不中断
当父类 A → 子类 B → 子类 C 都实现了 clone()，且都希望支持深拷贝时，“克隆链”不是自动连通的。每个 clone() 方法只负责自己那一层的字段，而 super.clone() 返回的是父类视角的浅拷贝 —— 它不会触发父类里写的深拷贝逻辑。
也就是说：C.clone() 调用 super.clone()（即 B.clone()），但若 B.clone() 写的是 return (B) super.clone();（没处理 B 的字段），那 B 层的深拷贝就丢了。
- 每层子类的
clone()必须显式调用父类的clone()（而非super.clone()），前提是父类已把clone()声明为public - 更稳妥的做法：父类提供
protected Object shallowClone()，让子类统一调用，并在各自clone()中完成本层深拷贝 - 避免在父类
clone()中直接 new 子类实例（破坏开闭原则），也不要让子类覆盖clone()后忘记调用父类逻辑
替代方案比 clone() 更可靠吗
是的。Cloneable 接口设计有缺陷：它没有定义 clone() 方法，无法强制实现，且语义模糊。很多团队已转向更明确的替代方式。
- 使用拷贝构造函数：
public Order(Order other)，意图清晰，类型安全，IDE 和静态检查工具能更好支持 - 使用工厂方法或 builder 模式重建对象，尤其适合字段多、逻辑复杂的场景
- 序列化反序列化（如
ObjectOutputStream）可全自动深拷贝，但要求所有字段可序列化，且性能差、无法处理 transient 或非 Serializable 字段 - Lombok 的
@AllArgsConstructor+ 手动 copy 逻辑，比@Data+clone()更可控
真正容易被忽略的一点：即使你把每一层 clone() 都写对了，只要依赖的某个第三方类没正确实现 clone()（比如某 SDK 的 RequestContext 类只返回浅拷贝），整个链就失效 —— 这种隐式耦合很难测试和排查。
