当对象未实现Cloneable接口却调用Object.clone()时，JVM抛出受检异常CloneNotSupportedException；需显式捕获并转为语义化异常，或通过实现Cloneable、使用拷贝构造器等更可靠方式替代。
当对象未实现 Cloneable 接口却调用 clone() 方法时，JVM 会抛出 CloneNotSupportedException。这不是一个运行时异常，而是受检异常（checked exception），必须显式处理——不能忽略，也不能靠 JVM 自动兜底。
理解 CloneNotSupportedException 的触发时机
该异常只在以下条件同时满足时抛出：
- 调用的是
Object.clone()（即未被子类重写或重写后仍调用super.clone()） - 当前对象的**直接类**未实现
Cloneable接口（父类实现了不算数） - 该调用发生在编译期类型为非
Cloneable的引用上（例如声明为Object obj = new MyData();，而MyData没实现接口）
注意：如果类已实现 Cloneable，即使没重写 clone()，调用 super.clone() 也不会抛此异常；如果重写了但忘了加 Cloneable，则仍会抛出。
正确捕获与响应异常
不要用空 catch 块吞掉它，也不该直接抛出给上层不加说明。推荐方式是：
- 在业务方法中明确捕获，转为更语义化的异常，如
UnsupportedOperationException或自定义的ImmutableCopyException - 若克隆是可选能力，可记录 warn 日志并返回原对象引用（需确保调用方能接受“未复制”语义）
- 避免在工具类通用 clone 方法里静默 fallback 到序列化复制——这会掩盖设计意图，且序列化本身也有额外约束和性能开销
预防优于处理：主动声明克隆能力
真正健壮的做法不是等异常发生再处理，而是从设计上让克隆意图清晰可见：
- 需要支持浅克隆的对象，必须显式实现
Cloneable并重写clone()，且在 Javadoc 中注明线程安全性和字段复制策略 - 对不可变对象或明确禁止复制的类型，可重写
clone()主动抛出UnsupportedOperationException，比依赖CloneNotSupportedException更直观 - 在 API 层（如 DTO 工具类）提供
safeClone(T obj)方法，内部先用obj instanceof Cloneable检查，再决定是否调用clone()，把异常拦截在封装层内
替代方案比硬扛 clone() 更可靠
现代 Java 开发中，应优先考虑比 Object.clone() 更可控的复制方式：
- 构造器注入复制：提供
new MyType(other)形式的拷贝构造器，逻辑清晰、类型安全、支持深复制 - 静态工厂方法：如
MyType.copyOf(source)，便于统一处理 null、不可变字段、资源复制等边界 - 记录类（record）天然不可变，无需 clone；如需“修改副本”，用 withers 模式或构建器
- 序列化复制仅作备选，须确保类及所有字段可序列化，并注意 transient 字段丢失风险
