Go无原型模式但可借Clone()模拟，需手动深拷贝切片、map及指针字段，避免共享底层数据；gob深拷贝性能差且类型不安全，仅适合结构极不稳定场景。
Go 没有内置原型模式，但可以用 Clone() 方法模拟
Go 语言本身不支持类、继承或 clone 关键字，所以不存在传统 OOP 意义上的“原型模式”。但你可以通过为结构体定义 Clone() 方法（返回新副本）来达成相同目的：避免重复初始化、复用已有对象状态。
关键不是“模式名称”，而是“是否需要深拷贝”——如果对象含指针、切片、map 或嵌套结构，直接赋值会共享底层数据，这不是真正克隆。
- 简单结构体（只含基本类型、字符串）可直接用
obj2 := obj1 - 含
[]int、map[string]int、*SomeStruct的结构体，必须手动深拷贝字段 - 不要依赖
reflect.DeepCopy：标准库没有这个函数；第三方包如github.com/jinzhu/copier或gob编码虽可用，但有性能/类型限制
如何写一个安全的 Clone() 方法
以常见含切片和 map 的结构体为例：
type Config struct {
Name string
Tags []string
Props map[string]interface{}
Owner *User
}
func (c *Config) Clone() *Config {
if c == nil {
return nil
}
clone := &Config{
Name: c.Name,
// 手动复制切片
Tags: make([]string, len(c.Tags)),
}
copy(clone.Tags, c.Tags)
// 手动复制 map
clone.Props = make(map[string]interface{}, len(c.Props))
for k, v := range c.Props {
clone.Props[k] = v // 注意：interface{} 中若含 map/slice/ptr，仍需递归处理
}
// 指针字段按需克隆（这里假设 User 也有 Clone）
if c.Owner != nil {
clone.Owner = c.Owner.Clone()
}
return clone
}
要点：
立即学习“go语言免费学习笔记（深入）”；
- 始终检查
c == nil，避免 panic -
copy()是切片深拷贝最高效方式；make + append也可，但多一次分配 -
map必须make新实例再遍历赋值；直接clone.Props = c.Props会共享引用 - 嵌套指针（如
*User）要明确决定：是浅拷贝指针，还是调用其Clone()——这取决于业务语义
用 encoding/gob 做通用深拷贝？谨慎
有人用 gob 编码再解码实现“无侵入深拷贝”，例如：
func DeepClone(v interface{}) interface{} {
var buf bytes.Buffer
enc := gob.NewEncoder(&buf)
dec := gob.NewDecoder(&buf)
enc.Encode(v)
var clone interface{}
dec.Decode(&clone)
return clone
}
问题很多：
- 仅支持
gob可序列化的类型（不支持func、chan、含不可导出字段的 struct） - 性能差：涉及内存分配、编码/解码开销，比手写
Clone()慢 10–100 倍 - 丢失类型信息：
clone是interface{}，需断言回原类型 - 无法控制克隆粒度（比如某些字段想跳过、某些字段想用自定义逻辑）
除非原型对象结构极不稳定且你完全放弃性能与类型安全，否则不推荐。
什么时候该用 Clone() 而不是重新 new 或 &Struct{}
典型场景是“基于模板创建变体”：
- HTTP 请求上下文复用：从一个基础
Context克隆出多个带不同Value的子上下文（虽然标准库用的是WithValue，但原理类似） - 配置热更新：加载一份主配置，每次请求前
Clone()并注入临时参数 - 游戏实体生成：NPC 模板对象克隆后修改 ID、位置、血量等
注意：如果克隆后几乎总要重设大部分字段，那不如重构为工厂函数 + 参数化构造，Clone() 反而增加维护负担。
真正容易被忽略的是字段生命周期——比如克隆一个含 sync.Mutex 的结构体，直接复制会导致两个对象共用一把锁，引发竞态。这类非可复制字段必须在 Clone() 中显式重置（如 clone.mu = sync.Mutex{}）或跳过复制。
