Go无内置深拷贝，需手动递归或序列化实现；手动递归用reflect遍历重建值，注意处理指针、struct、slice、map、interface等类型及循环引用。
Go 里没有内置的深拷贝，copy 和赋值都只是浅拷贝
Go 的指针、切片、map、struct 字段如果含引用类型，直接赋值或 copy 只会复制顶层地址，底层数据仍共享。比如两个 struct 指针指向同一块内存，改其中一个的 map[string]int 字段，另一个也会变——这不是你想要的“深拷贝”。
真正需要深拷贝时，只有两条路：手动递归遍历 + 新建对象，或走序列化/反序列化绕道。别指望 reflect.Copy 或 unsafe 能帮你省事，它们不解决语义层面的复制逻辑。
- 手动递归适合结构固定、字段可控的场景（如自定义配置结构体），能精确控制哪些字段要拷贝、哪些跳过（比如忽略函数字段或
sync.Mutex） - 序列化方式（如
json.Marshal+json.Unmarshal）简单粗暴，但要求字段可导出、支持对应编码器，且会丢掉未导出字段、chan、func、unsafe.Pointer 等 - 注意：所有方案都无法自动处理循环引用，手动递归必须加 visited map 判断，序列化库（如
gob）部分支持，但json直接 panic
手动递归深拷贝：用 reflect 遍历并重建值
核心是用 reflect.ValueOf 获取原始值，再用 reflect.New 和 reflect.Indirect 构造新实例，对每个字段递归处理。不能直接 reflect.Copy，它只做浅层内存复制。
常见错误现象：panic: reflect.Copy: unaddressable value —— 因为传入的是不可寻址的 reflect.Value（比如从 map 取出来的值）；或者没处理指针层级，导致 nil panic。
立即学习“go语言免费学习笔记（深入）”；
- 入口必须传入指针（
*T），否则无法构造新地址空间 - 遇到
reflect.Ptr类型，先判断是否为 nil；非 nil 则递归处理其Elem() - 遇到
reflect.Struct，遍历每个字段：若字段可导出，递归拷贝；否则跳过（无法写入未导出字段） - 遇到
reflect.Slice或reflect.Map，先MakeSlice/MakeMapWithSize，再逐个元素递归 - 遇到
reflect.Interface，需先取内部值再递归（避免只拷贝 interface header）
示例关键片段：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func DeepCopy(v interface{}) interface{} {
rv := reflect.ValueOf(v)
if rv.Kind() != reflect.Ptr {
panic("DeepCopy expects pointer")
}
return copyValue(rv.Elem()).Interface()
}
func copyValue(v reflect.Value) reflect.Value {
if !v.IsValid() {
return reflect.Zero(v.Type())
}
switch v.Kind() {
case reflect.Ptr:
if v.IsNil() {
return reflect.Zero(v.Type())
}
nv := reflect.New(v.Elem().Type())
nv.Elem().Set(copyValue(v.Elem()))
return nv
case reflect.Struct:
nv := reflect.New(v.Type()).Elem()
for i := 0; i < v.NumField(); i++ {
if !v.Field(i).CanInterface() { continue }
nv.Field(i).Set(copyValue(v.Field(i)))
}
return nv
// ... 其他 kind 处理
}
}
序列化方式：选 gob 还是 json？
gob 是 Go 原生二进制格式，支持未导出字段、interface、chan（但不推荐）、自定义 GobEncode 方法；json 更通用但限制多：只处理导出字段，不支持 func/map[interface{}]interface{}/time.Time（需额外处理），且性能略低。
容易踩的坑：json.Marshal 对含 nil slice 或 map 返回 null，反序列化后变成 nil 而非空值；gob 要求注册自定义类型（如果用了 interface{} 存不同结构）；两者都不处理循环引用，gob 会死锁，json 直接 panic。
- 用
gob时，务必在 encode 前调用gob.Register注册所有可能出现在 interface{} 中的类型 - 用
json时，给 struct 加json:",omitempty"不影响深拷贝逻辑，但要注意零值字段会被忽略，反序列化后可能不是你期望的“空”而是“未设置” - 性能上，
gob通常比json快 2–3 倍，尤其对嵌套 struct；但若需跨语言交互，只能选json或protobuf
深拷贝失败最常被忽略的点：不可复制字段和运行时状态
无论手动还是序列化，以下字段永远无法（也不应该）被深拷贝：sync.Mutex、sync.RWMutex、chan、func、unsafe.Pointer、net.Conn 等。它们代表运行时状态或操作系统资源，复制无意义甚至危险。
典型表现：手动递归中对 reflect.Func 调用 Call panic；json 序列化含 sync.Mutex 的 struct 报错 “json: unsupported type: sync.Mutex”；gob 编码未注册的自定义 interface{} 类型失败。
- 手动方案中，遇到这些类型应直接跳过、置零或 panic 提示（取决于业务容忍度）
- 序列化方案中，提前用
json:"-"或gob:"-"忽略敏感字段 - 真正需要“复制行为”的场景（比如测试中 mock 一个带锁的 config），应该重构设计：把状态和数据分离，只深拷贝纯数据部分
深拷贝从来不是银弹。它要么代价高（反射慢、序列化占内存），要么语义模糊（到底该不该复制锁？要不要重连 socket？）。多数时候，问题根源不在“怎么拷”，而在“为什么需要拷”。
