Go无原型模式语法支持，克隆需手动实现：值类型字段直接赋值即可；含切片、map、指针时须深拷贝；gob仅适用于纯数据结构，性能差且有类型限制；手写Clone()最可控但需处理nil边界和嵌套语义。
Go 语言没有原型模式的语法支持，也没有内置 Clone() 方法——这不是缺陷，而是设计选择。你要克隆对象，就得自己决定“哪些字段要隔离、哪些可共享、哪些必须重置”。
什么时候直接赋值就足够？
结构体只含 int、string、bool、time.Time 或固定长度数组时，a := b 是安全、高效、真正的副本。
- 修改
a.Name不会影响b.Name - 底层无指针/引用共享，无需额外逻辑
- 常见于 DTO、配置快照、测试用例中的简单模型
一旦出现 []string、map[string]int、*User、chan int，赋值就变成浅拷贝——后续对副本的 append() 或 delete() 会意外污染原对象。
为什么 encoding/gob 深拷贝常踩坑？
gob 是标准库里最接近“通用深拷贝”的方案，但它的行为和限制非常具体：
立即学习“go语言免费学习笔记（深入）”；
- 所有字段必须导出（首字母大写），未导出字段（如
privateData int）会被静默忽略 - 含
func、chan、unsafe.Pointer、sync.Mutex的结构体会在Encode或Decode时 panic - 每次调用都要新建
bytes.Buffer和编解码器，重复使用gob.Encoder可能导致 panic - 性能比手写
Clone()低 5–10 倍，不适合高频路径（如每秒万级请求的 handler）
它适合一次性克隆纯数据结构（如 API 请求参数、YAML 解析后的配置），不适合带状态或并发控制字段的对象。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
手动实现 Clone() 方法的关键细节
为结构体定义 Clone() 是最可控的方式，但容易漏掉边界情况：
-
nil切片：不能直接make([]T, len(src))，得先判空，否则 panic -
nilmap：要用make(map[K]V)而非make(map[K]V, len(src))，后者对 nil map 无效 - 嵌套指针：若字段是
*Config，且Config自身有Clone()，就得递归调用src.Inner.Clone() - slice 复制推荐用
append([]T(nil), src...)，比make + copy更简洁且自动处理 nil
示例中常见错误是把 Props map[string]interface{} 当作扁平键值复制——如果 value 是 []byte 或另一个 struct 指针，不递归处理仍会共享底层内存。
第三方库如 copier 真的省心吗？
github.com/jinzhu/copier 可以自动匹配字段名并复制，但它默认仍是浅拷贝：
- 对
[]string字段，它只复制 slice header，底层数组仍共享 - 遇到
interface{}，无法自动识别内部类型，可能跳过或 panic - 不支持自定义字段逻辑（比如克隆时重置
CreatedAt为当前时间） - 依赖反射，编译期无法检查字段是否存在，运行时才发现拼写错误
它适合快速填充 DTO 或做一次性的数据迁移，但不能替代你对业务语义的理解——比如连接池对象克隆后，必须重置 activeConn 计数器，而不仅仅是复制字段。
真正难的不是“怎么克隆”，而是判断“哪些字段不该克隆”。比如一个含 io.ReadCloser 字段的结构体，克隆时通常应该重新打开文件或重建 reader，而不是试图复制句柄。
