proto.clone 仅适用于 protobuf.message 类型，依赖生成代码的 xxx_clone 方法，非通用深拷贝方案；手写 clone 最高性能且可控，适合高吞吐生产环境。
Go 里用 proto.Clone 还是手写深拷贝？
直接说结论：proto.Clone 只对实现了 protobuf.Message 接口的结构体有效，且依赖生成代码中的 XXX_clone 方法；它不是通用对象拷贝方案，和“序列化复制”（如 json.Marshal + json.Unmarshal）完全不在同一抽象层。
常见错误是把 proto.Clone 当成 Go 原生深拷贝工具——它不处理普通 struct、map、slice，也不支持自定义类型，一旦传入非 proto 消息，会 panic：panic: interface conversion: interface {} is not proto.Message。
- 适用场景：你已经在用 Protocol Buffers，且所有要拷贝的对象都由
protoc-gen-go生成，字段全是 protobuf 内建类型或嵌套消息 - 性能优势明显：
proto.Clone是零分配内存的浅层指针复制 + 懒惰克隆（lazy clone），比任何序列化方式快 5–10 倍 - 坑点：如果 proto 消息里嵌了
map[string]interface{}或json.RawMessage，这些字段不会被克隆，原地共享引用
json.Marshal + json.Unmarshal 拷贝为什么慢又危险？
这是最常被误用的“通用深拷贝”手段。它确实能绕过类型限制，但代价极高，且语义不可靠。
典型错误现象：拷贝后时间字段变成零值、nil slice 变成空 slice、自定义 UnmarshalJSON 方法被意外触发、浮点数精度丢失、time.Time 被转成字符串再解析导致时区错乱。
立即学习“go语言免费学习笔记（深入）”；
- 性能差：至少两次内存分配（序列化字节流 + 反序列化解析），GC 压力大；小对象也至少 2–3μs，大结构轻松破毫秒
- 不兼容私有字段：未导出字段（首字母小写）直接被忽略，拷贝后为零值
- 无法还原原始类型：比如
type UserID int64经 json 走一遭，反序列化出来只是int64，类型信息丢失 - 别用在 hot path：HTTP handler 里每请求一次都这么拷，QPS 下降立竿见影
什么时候该用 github.com/jinzhu/copier 或 gob？
copier.Copy 是反射型拷贝库，适合快速原型或配置结构体拷贝；gob 是 Go 原生二进制序列化，能保留类型，但仅限 Go 进程间通信。
注意：copier 默认跳过 nil 指针字段，且不递归处理 map/slice 元素（除非显式开启 DeepCopy），而 gob 要求所有类型可注册，且不能跨 Go 版本兼容。
-
copier.Copy(dst, src)：适合字段名匹配、无嵌套逻辑的扁平结构，比如从 API 请求体拷到 DB 模型 -
gob：仅用于临时内存拷贝（如 cache 预热），不要用于持久化或跨服务传输，gob编码不保证向后兼容 - 两者都逃不开反射开销：比
proto.Clone慢一个数量级，比手写赋值慢 3–5 倍
真正高性能的拷贝：手写或代码生成
Go 没有泛型深拷贝的银弹。生产环境高吞吐场景下，唯一靠谱的是：要么手写 Clone() 方法，要么用 go:generate 工具自动生成。
例如给结构体加方法：
func (u *User) Clone() *User {
if u == nil {
return nil
}
c := &User{
ID: u.ID,
Name: u.Name,
Tags: append([]string(nil), u.Tags...), // slice 深拷贝
Meta: maps.Clone(u.Meta), // Go 1.21+ maps.Clone
}
return c
}
- 手写可控、无反射、零额外分配，但维护成本随字段增加而上升
- 推荐搭配
ent或sqlc这类代码生成器，在生成 model 时一并注入Clone方法 - 切记检查所有复合字段：slice 要
append或copy，map 要maps.Clone（1.21+）或手动遍历，指针字段需判断是否为 nil
最容易被忽略的是：嵌套结构体里某个字段是接口类型（如 io.Reader），这种根本没法通用拷贝，必须业务层明确约定行为——不是所有“拷贝”都该是深的，有时候共享才是正确语义。
