直接调用 clone() 抛 CloneNotSupportedException 是因为 Object.clone() 受保护且仅允许实现 Cloneable 接口的类调用；该接口为空但被 JVM 特殊识别，未实现则运行时抛异常，编译却通过。
为什么直接调用 clone() 会抛 CloneNotSupportedException
因为 Object.clone() 是受保护的，且默认只允许实现了 Cloneable 接口的类调用。这个接口是空的（marker interface），但它在 JVM 层面被特殊识别——没实现就调用 clone()，JVM 直接扔异常。
常见错误现象：java.lang.CloneNotSupportedException 在运行时突然冒出，但编译完全通过。
- 必须显式声明
implements Cloneable，光重写clone()不够 -
Cloneable接口本身不定义任何方法，所以不会自动提供clone()方法 - 子类如果继承自未实现
Cloneable的父类，即使自己实现了，调用super.clone()仍可能失败
浅克隆 vs 深克隆：什么时候 clone() 会悄悄改掉原对象
默认的 Object.clone() 是浅克隆：基本类型字段复制值，引用类型字段只复制引用地址。这意味着原对象和克隆体共用同一份内部对象，修改其中一个的集合、数组或可变对象，另一个也会“感知”到。
使用场景：仅当对象所有字段都是不可变类型（如 String、Integer）或你明确希望共享引用时，才可放心用默认行为。
立即学习“Java免费学习笔记（深入）”；
- 含
ArrayList、HashMap、自定义可变对象的类，必须手动深克隆关键字段 - 不要依赖序列化或第三方库来“绕过”这个问题——它们解决的是深克隆，但掩盖了设计意图
- 注意嵌套层级：若字段 A 引用 B，B 又引用 C，需逐层判断是否需要克隆
示例（修复浅克隆陷阱）：
public class Person implements Cloneable {
private String name;
private ArrayList<String> hobbies;
@Override
public Person clone() {
try {
Person cloned = (Person) super.clone();
// 手动深克隆可变引用字段
cloned.hobbies = new ArrayList<>(this.hobbies);
return cloned;
} catch (CloneNotSupportedException e) {
throw new AssertionError(); // 不可能发生，因已实现 Cloneable
}
}
}
重写 clone() 方法时的几个硬性约定
Java 规范要求 clone() 必须满足三个条件：返回新对象、与原对象 equals()（如果重写了）、不调用任何构造函数。违反任一，下游使用者就会踩坑。
- 返回类型建议用具体类名（如
Person clone()），而非Object，避免每次调用都强转 - 不能在
clone()中调用this.xxx = new Xxx()初始化字段——这违背“不走构造逻辑”的契约 - 如果类有 final 字段，且该字段指向可变对象，无法在
clone()中重新赋值（final 不允许二次赋值），此时Cloneable基本不可行，应改用拷贝构造函数或工厂方法 - 涉及线程安全字段（如
AtomicInteger）时，直接复制引用通常没问题，因其自身是线程安全的
替代方案比 Cloneable 更可靠？什么情况下该放弃它
是的。很多团队实际已弃用 Cloneable，因为它的契约模糊、异常处理别扭、泛型不友好，且和 final、不可变设计天然冲突。
使用场景：当你需要克隆逻辑稳定、可测试、能随类演进而维护时。
- 优先用拷贝构造函数：
public Person(Person other)，语义清晰，支持 final 字段，IDE 友好 - 对复杂对象，用静态工厂方法：
Person.from(other)，便于添加校验或转换逻辑 - 若必须用克隆（如框架强制要求），至少把
clone()设为protected，对外只暴露更安全的封装方法 - 注意：Spring、Hibernate 等框架内部克隆逻辑往往绕过
Cloneable，直接反射或字节码操作——别假设框架会按你的clone()实现执行
真正容易被忽略的是：Cloneable 和序列化一样，属于“隐式契约”，不看源码根本不知道一个类是否真的能安全克隆。与其赌文档，不如一开始就控制克隆入口。
