clonenotsupportedexception是jvm在native层校验cloneable标记失败所致，非java代码抛出；类必须显式implements cloneable（大小写敏感、不可继承），否则super.clone()直接拒绝执行。
CloneNotSupportedException 是 JVM 的准入凭证检查
这个异常不是 Java 代码抛出的，而是 JVM 在 native 层执行 super.clone() 前做的硬性校验：只要目标类的 Class 对象没被标记为实现了 Cloneable，就直接拒绝执行内存拷贝，立刻抛出 CloneNotSupportedException。它本质上是一张“入场券”——没有实现 Cloneable 接口，连克隆的门都进不去，更别说浅拷贝还是深拷贝了。
标记接口不提供能力，只表达契约意图
Cloneable 没有方法、不能被继承、大小写敏感、也不能靠父类实现来传递授权。子类必须自己显式声明 implements Cloneable。这说明它的作用不是添加功能，而是向运行时明确声明“我允许被克隆”。这种设计把语义责任交还给开发者：JVM 不替你判断是否安全，只认这个标记；你打了勾，才承担后续拷贝逻辑（比如字段是否可变、final 怎么处理）的全部后果。
异常暴露了 clone() 机制的脆弱性边界
- 即使重写了 public Object clone()，没加接口照样报错
- 即使父类实现了 Cloneable，子类不声明，调用时仍抛异常
- 即使 try-catch 住异常，也改不了 JVM 底层的拒绝逻辑
- final 字段或引用类型字段不会导致这个异常，但会让克隆结果出错——那已是另一层问题
也就是说，CloneNotSupportedException 只管“能不能克隆”，不管“克得对不对”。它用一个清晰的失败信号，划出了 Java 克隆机制的原始边界：标记即许可，无标即禁令。
对比 Serializable 更能看出标记接口的设计逻辑
Serializable 也是空标记接口，但它的作用是开启序列化流程；而 Cloneable 是开启 native 内存拷贝流程。两者都不定义行为，却各自触发 JVM 完全不同的底层路径。这说明 Java 用标记接口做运行时开关，不是为了省事，而是为了把语义控制权和风险责任牢牢绑定在类的声明上——不写 implements，就是不参与，不担责，也不被执行。
