Go中原型模式本质是值拷贝，通过struct赋值或copy实现轻量创建；含指针/map/slice等需手动深拷贝，避免逻辑错误；高吞吐场景禁用json/gob序列化，应手写Clone方法或用sync.Pool复用。
原型模式在 Go 中本质是值拷贝，不是传统意义上的“原型”
Go 没有类、没有继承、没有 clone() 方法，所谓“原型模式”只是开发者对“用已有对象快速创建新实例”这一意图的模拟。实际落地几乎全靠 struct 的值复制（= 赋值）或 copy() 函数，底层不涉及反射或运行时类型重建，所以天然轻量。
但要注意：如果结构体包含指针、map、slice、chan 或 func 字段，直接赋值只会复制这些字段的引用，不是深拷贝 —— 这不是性能问题，而是逻辑错误源头。
- 纯字段都是基本类型或小 struct？
obj2 := obj1就够了，零分配、纳秒级 - 含
slice且需独立副本？必须手动append([]T(nil), obj1.Data...)或用make+copy - 含
map？必须for k, v := range obj1.Config { newMap[k] = v }，不能直接赋值
深拷贝别碰 gob 或 json，它们会拖垮高性能场景
有人用 json.Marshal + json.Unmarshal 实现“通用深拷贝”，这在原型模式演示代码里很常见，但在高吞吐服务中是灾难：
-
json编解码要反射、要内存分配、要字符串转换，一次拷贝常耗时 >10μs，比纯内存拷贝慢 3–4 个数量级 -
gob稍快但仍有编码开销，且不支持未导出字段、不兼容跨版本结构体变更 - 即使加了
sync.Pool缓存*bytes.Buffer，也无法掩盖序列化本身带来的延迟毛刺
真正需要深拷贝时，应手写专用克隆方法，例如：
立即学习“go语言免费学习笔记（深入）”；
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
func (u User) Clone() User {
u2 := u
u2.Addresses = append([]string(nil), u.Addresses...)
u2.Metadata = maps.Clone(u.Metadata) // Go 1.21+
return u2
}
并发安全的原型复用：用 sync.Pool 替代反复 new + init
高频创建临时对象（如网络请求上下文、解析中间结构体）时，“原型模式”的合理用法其实是预分配 + 复用，而非每次从头拷贝。这时 sync.Pool 比手动维护原型实例更合适：
-
sync.Pool回收的是真实堆对象，避免 GC 压力；而原型赋值仍是栈/堆上的新副本，不减少分配次数 - 若原型对象本身带状态（比如含计数器、缓存 map），直接复用会引发数据竞争 —— 必须在
Get()后重置关键字段 - 注意
Pool.New是懒加载，首次Get()才调用，别假设它总提前初始化好
典型写法：
var userPool = sync.Pool{
New: func() interface{} {
return &User{Addresses: make([]string, 0, 4)}
},
}
// 使用时：
u := userPool.Get().(*User)
*u = User{} // 清空可变字段，或逐个重置
u.Name = "xxx"
// ...
userPool.Put(u)
真正影响性能的从来不是“拷贝动作”，而是逃逸分析和内存布局
Go 编译器会根据变量使用方式决定是否逃逸到堆。一个看似简单的 u2 := u，如果 u2 被返回、传入接口、或取地址后逃逸，就会触发堆分配 —— 这比拷贝本身代价高得多。
验证方式很简单：go build -gcflags="-m -l"，看关键结构体是否出现 ... escapes to heap。
- 尽量让结构体字段紧凑、按大小降序排列（
int64在前，bool在后），减少 padding - 避免在结构体里塞大数组（如
[1024]byte），它会让整个 struct 强制堆分配 - 如果原型对象生命周期短且局部，编译器大概率优化成栈上复制，这时候谈“原型模式性能”其实是在谈汇编指令数
所谓高性能场景下的“原型模式”，最终拼的不是设计模式名字，而是你有没有看过逃逸分析输出、有没有为每个 slice 写对 make 容量、以及是否真的需要深拷贝——还是说，只改几个字段就够了。
