CloneNotSupportedException 根源是类未显式声明 implements Cloneable 接口，即使重写了 clone() 方法；必须 public 重写 clone()、手动处理引用类型深拷贝、数组和 final 字段需特殊处理，但原生 clone 机制脆弱，推荐用构造函数、静态工厂或序列化替代。
CloneNotSupportedException 本质是没实现 Cloneable 接口
抛这个异常不是因为你调用了 clone() 方法写错了，而是 JVM 在运行时发现目标类没声明自己“可克隆”。Java 的 clone() 是个受保护的 native 方法，它底层会检查类是否实现了 Cloneable 接口——没实现就直接扔 CloneNotSupportedException。
常见错误现象：new MyClass().clone() 直接崩溃，堆栈里明确写着 java.lang.CloneNotSupportedException: MyClass；但你翻源码发现 MyClass 确实重写了 clone()，却漏了接口声明。
- 必须显式 implements
Cloneable（空接口，纯标记用） -
Cloneable接口不能写在父类里让子类“继承”——子类自己也得声明 - 接口名大小写敏感：
cloneable或Clonable都无效
重写 clone() 时别忘了设为 public
Object.clone() 是 protected 的，子类不改访问级别，外部代码根本调用不到。即使加了 Cloneable，也会报编译错误或 IllegalAccessError。
使用场景：工具类封装克隆逻辑、DTO 转换、测试中快速构造相似对象。
立即学习“Java免费学习笔记（深入）”；
- 必须把重写方法改成
public，返回类型建议用具体类（如MyClass），避免强制转型 - 别只写
return super.clone();就完事——如果类里有引用类型字段（比如List、Map），默认是浅拷贝，后续修改可能互相污染 - 若字段含可变对象，需手动深拷贝：例如
this.items = new ArrayList(original.items);
数组字段和 final 字段要特别处理
数组是对象，super.clone() 对数组只做浅拷贝——新对象里的数组引用指向原数组，改一个全改。而 final 字段在 clone 过程中无法直接赋值，编译会报错。
性能影响：深拷贝数组（尤其是大数组）会多一次内存分配和复制，比浅拷贝慢；但不处理会导致逻辑 bug，比性能问题更严重。
- 数组字段推荐用
Arrays.copyOf()或clone()显式拷贝：this.data = this.data.clone(); -
final字段不能在 clone 方法里直接赋值（违反 final 语义），但可以通过反射绕过——不推荐；更稳妥的是把字段设计成非 final，或改用不可变容器（如ImmutableList） - 如果用了 Lombok，
@Data不会自动生成 clone 支持，@AllArgsConstructor+Cloneable也不行，得手写或配@Builder替代
替代方案比硬刚 clone() 更可靠
Java 原生 clone 机制太脆弱：依赖接口标记、访问权限、字段语义理解，还分不清浅/深、final、泛型擦除等问题。很多团队已弃用。
兼容性影响：Android 低版本对 clone 支持不稳定；某些序列化框架（如 Kryo）会跳过 clone 逻辑，导致行为不一致。
- 优先用构造函数传参复制：
new MyClass(src.getA(), src.getB()) - 用静态工厂方法：
MyClass.from(other)，内部可控、可文档化、可加校验 - 需要通用克隆时，用 Jackson 或 Gson 序列化再反序列化（注意 transient 字段和无参构造函数要求）
真正难的不是怎么 catch 这个异常，而是意识到：只要类结构稍复杂，clone() 就容易漏掉某个字段的拷贝逻辑——这种隐式契约，比明写的构造逻辑更难维护。
