热路径中禁用json.Marshal深拷贝，应手写DeepCopy或用sync.Pool复用对象，读多写少场景优先采用COW模式。JSON序列化性能差、GC压力大；手动深拷贝需注意指针、slice、map等引用类型；sync.Pool可降低高频分配开销；COW要求副本不可变且原子切换。
热路径里用 json.Marshal 深拷贝就是自找麻烦
很多团队在配置热更新、缓存快照等高频场景下，第一反应是用 json.Marshal + json.Unmarshal 做深拷贝——写起来快，类型安全，还能跨进程序列化。但实测数据很打脸：JSON 序列化方式比手动复制慢 8 倍以上，内存分配多 8 倍，GC 压力直线上升。热路径每秒调用几百次，这种开销会迅速放大成 P99 延迟毛刺甚至 GC STW 抖动。
根本原因在于：JSON 要走完整的词法解析、反射字段遍历、字符串拼接、堆内存反复申请释放。它不是为内存内高速复制设计的，而是为跨语言/网络传输妥协出来的通用格式。
- 别在热路径里用
json、gob或任何基于反射的通用序列化库做深拷贝 - 如果结构体字段固定且已知（比如配置结构体
Config、请求上下文RequestCtx），必须手写DeepCopy方法 - 注意字段是否含指针、
[]byte、map[string]interface{}等引用类型——这些才是需要深拷贝的点，基本类型和字符串可直接赋值
浅拷贝不是不能用，但得清楚它“浅”在哪一层
Go 的结构体赋值默认是浅拷贝，但这个“浅”只作用于结构体字段本身。如果字段是 []string，那 slice header（指针、长度、容量）被复制了，底层数组仍共享；如果是 *int，那指针值被复制，指向的同一块内存；但如果是 string，由于其底层是只读的 struct{ptr, len}，赋值后两个 string 互不影响——这是 Go 的特殊保障，不是深拷贝。
所以判断能否用浅拷贝，关键看业务是否允许“副本修改 slice/map/指针字段时原对象也被改”：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 读多写少、副本仅用于只读快照（如配置快照、日志上下文）→ 浅拷贝够用，零成本
- 副本要修改嵌套 slice 或 map → 必须对这些字段单独深拷贝，其他字段仍可浅拷贝
- 结构体含
sync.Mutex或atomic.Value→ 绝对不能浅拷贝，会破坏并发安全语义
复用比复制更快：用 sync.Pool 管理副本对象
即使手写了 DeepCopy，每次调用仍要 new 结构体、分配 slice 底层数组、复制字段——这仍是堆分配。在超高频路径（如每毫秒数百次），sync.Pool 可显著降低 GC 压力。
典型做法是把副本对象封装进一个可复用的容器里：
var personPool = sync.Pool{
New: func() interface{} {
return &Person{}
},
}
func (p *Person) CopyToPool() *Person {
dst := personPool.Get().(*Person)
// 手动深拷贝字段到 dst
dst.Name = p.Name
if p.Age != nil {
ageCopy := *p.Age
dst.Age = &ageCopy
}
dst.Hobbies = append(dst.Hobbies[:0], p.Hobbies...)
return dst
}
func (p *Person) ReturnToPool() {
personPool.Put(p)
}
-
sync.Pool不保证对象一定被复用，但能极大减少小对象高频分配 - 务必在使用完后调用
ReturnToPool，否则 pool 会持续持有对象，导致内存泄漏 - pool 中的对象可能被 GC 清理，所以
Get()后必须重置所有字段，不能假设内容干净
写时复制（COW）适合读远多于写的全局状态
像配置中心、路由表、元数据缓存这类场景，读操作占比 >99%，写极少但要求原子切换。这时最高效的方式不是每次“拷贝”，而是让读端直接访问当前版本指针，写端生成新副本后原子替换指针——这就是 atomic.Pointer + COW 的核心逻辑。
关键约束很明确：
- 副本对象必须是不可变的（即创建后不再修改其字段）
- 所有字段的深拷贝必须在写端一次性完成，不能边读边改
- 读端拿到的是指针，必须用
atomic.LoadPointer安全读取，避免看到中间态
一旦违反其中一条（比如副本里有个 map 被后续修改），整个隔离就失效了。这不是语法问题，是数据竞争的根源。
