clone() 比 new 快因直接复制内存二进制布局，绕过构造函数；但仅适用于无外部资源、可序列化的对象，否则引发资源冲突或崩溃。
为什么 clone() 比 new 快，但不是所有对象都能用它
因为原型模式绕过了构造函数和初始化逻辑，直接复制内存中的二进制布局。Java 的 Object.clone()、C# 的 MemberwiseClone()、Python 的 copy.copy()（浅拷贝）底层都依赖这一机制。但它只对“可序列化且无外部资源绑定”的对象安全——比如一个只含基本类型和不可变引用的 DTO；一旦对象里有 FileHandle、Socket、Thread 或带自定义 finalize() 的类，二进制复制会导致两个对象指向同一资源，运行时崩溃或数据错乱。
- Java 中必须显式实现
Cloneable接口，否则抛CloneNotSupportedException - C# 的
MemberwiseClone()是protected，子类需封装为public方法才能调用 - Python 的
copy.deepcopy()不走二进制流，而是递归重建，性能差一个数量级，别误当原型模式用
Java 里 clone() 报 CloneNotSupportedException 怎么办
这不是配置问题，是 Java 的强制契约：不声明自己“可克隆”，就不许克隆。即使你没写任何逻辑，也得让类实现 Cloneable 接口——它是个空标记接口，但 JVM 会检查这个 flag。
- 必须在类定义加
implements Cloneable，缺一个字母都不行 -
clone()方法要重写为public，否则子类无法调用 - 如果类有引用类型字段（如
ArrayList<string></string>），默认super.clone()只做浅拷贝，原对象和克隆体共享内部数组，后续修改会互相污染 - 深拷贝得手动 new 新集合、遍历 copy 元素，或者改用
SerializationUtils.clone()（Apache Commons），它靠序列化/反序列化实现真正的深克隆
C# 中 MemberwiseClone() 返回 object，怎么安全转型
它返回的是基类 object，不是当前类型，编译器不帮你自动转。硬转可能 runtime 失败，尤其继承链深或泛型类型复杂时。
- 最稳妥是用
as操作符：var cloned = this.MemberwiseClone() as MyClass;，失败时为null，可立刻判断 - 别用
(MyClass)this.MemberwiseClone()强转，一旦类型不匹配直接抛InvalidCastException - 如果类是泛型（如
MyClass<t></t>），MemberwiseClone()仍能工作，但返回类型仍是object，需配合as和非空检查 - 注意：值类型字段（
int、struct）会被完整复制，引用类型字段（string、List<t></t>）只复制引用，这点和 Java 一致
Python 用 pickle 模拟原型模式，为什么有时比 copy.deepcopy() 还慢
因为 pickle 要走编码/解码两道工序，本质是序列化到字节流再重建对象。它确实能绕过 __init__()，符合“跳过构造逻辑”的原型语义，但 IO 开销和反射解析成本高。
- 仅当对象结构极深、且含大量不可变数据（如嵌套 dict/list）时，
pickle才可能略快于deepcopy - 一旦对象里有不可 pickle 的东西（
lambda、打开的文件、模块级变量），直接报TypeError: can't pickle XXX objects - 真正高效的替代方案是手写
__copy__和__deepcopy__，把关键字段显式 new 出来，避免通用逻辑的遍历开销 - 如果只是想避免
__init__，更轻量的做法是用__new__+__dict__.update()，但要求类没有__slots__
原型模式的高效是有代价的：它把“对象状态一致性”的校验责任，从语言运行时移交给了程序员。二进制复制越快，越容易漏掉那些藏在 final 字段、静态缓存或 native 句柄里的隐性依赖。
