直接说结论:在C#里实现原型模式,别一上来就硬套ICloneable。优先考虑record with表达式,或者手写深拷贝逻辑。如果非得用ICloneable,那么Clone()方法必须自己重写,千万别指望MemberwiseClone()能解决问题——否则你改副本的时候,原对象也会跟着变,这可不是你想要的。

为什么 MemberwiseClone() 不是“能用就行”的克隆
MemberwiseClone() 是 object 的受保护方法,它只做浅拷贝:值类型字段复制值,引用类型字段只复制地址。这意味着克隆体和原对象会共享同一份 List、同一个 Equipment 实例,甚至同一个 Stream 对象。
想象一下这种场景:
- 你往
clone.Items.Add("new")里加了个新元素,结果original.Items里也多了一项。 - 你不小心调用了
clone.Weapon.Durability--,结果原对象的武器耐久度也跟着下降。 - 在文档编辑器里做 Undo 操作,上一版文档的图片列表居然被当前编辑污染了。
这可不是 bug,这是设计如此。浅拷贝适用的场景其实很窄:要么 class 里全是值类型字段,要么你本来就希望共享内部状态,比如共用一个缓存 ConcurrentDictionary。
用 record with 表达式替代传统克隆
C# 9 引入的 record 类型,天生就是为原型模式“基于旧值构造新值”这个语义准备的。编译器会保证字段级别的不可变性——除非你显式声明了 public set 或者放了可变引用字段。
什么时候用起来最顺手?
- 模型结构稳定,天然适合不可变语义(比如 DTO、配置快照、事件载荷)
- 不需要在运行时动态决定克隆深度,因为
with固定只做字段级复制 - 不依赖
ICloneable接口契约(比如第三方库强制要求传ICloneable的情况)
看个例子:
public record Person(string Name, int Age, ListTags); var original = new Person("Alice", 28, new() { "dev", "csharp" }); var copy = original with { Name = "Bob" }; // 注意:Tags 引用仍是共享的!
需要特别提醒的是:with 不等于深拷贝。如果你的 Tags 需要隔离,得手动处理:original with { Tags = new(original.Tags) }。
必须手写深拷贝时,Clone() 应该怎么写
当你必须返回 ICloneable、或者类型无法改造成 record、又或者对象里包含不可序列化的资源(比如 Socket、FileStream),那就得老老实实手写深拷贝了。
关键就几点:
- 每个引用类型字段都要显式新建实例,再把内容填进去(比如
new List,或者(source) source.Select(x => x.Clone()).ToList()) - 嵌套对象必须递归调用它自己的
Clone()方法,不能漏掉任何一层 - 尽量避免用
JsonSerializer.Serialize/Deserialize去处理那些有循环引用、非 public 字段、或者标注了[JsonIgnore]的类型 - 至于
BinaryFormatter,已经过时了,用了还得加[Serializable]标记,而且跨 .NET 版本反序列化也不靠谱
典型的写法是这样的:
public class NPC : ICloneable
{
public string Name { get; set; }
public Equipment Weapon { get; set; } // 假设 Equipment 也实现了 ICloneable
public object Clone() => new NPC
{
Name = this.Name,
Weapon = (Equipment)this.Weapon.Clone() // 关键:递归克隆
};
}
原型管理器(PrototypeRegistry)不是银弹
大型项目里,经常能见到 PrototypeRegistry 这种东西,用来管理预设的原型(比如游戏里的“兽人战士”、“精灵弓手”)。但说白了,它只是一个封装,解决不了拷贝本身的根本问题。
有几个容易被忽略的坑:
- 注册进 registry 的,必须是“干净”的原型实例——不能带着运行时状态,比如已打开的
Connection、已订阅的事件。 - registry 本身不控制克隆方式,
GetClone()返回的对象是否安全,完全取决于每个IPrototype.Clone()的实现质量。 - 如果原型里包含静态字段或者单例依赖,克隆之后依然会共享——原型模式解决不了设计耦合的问题。
简单场景下,直接 new 一个原型再 clone 反而更清晰。只有当原型创建的开销非常大(比如解析大 XML、加载纹理资源),并且需要频繁复用同一模板时,registry 才真正有价值。