reflect.copy仅做浅层元素复制，不处理指针、map、嵌套切片；深拷贝需手动递归创建新容器并逐字段处理，注意nil指针、未导出字段、interface{}值三类陷阱，性能差且不支持func等类型。
reflect.Copy 不能用于深拷贝
它只在切片间做元素级复制，且要求源和目标类型完全一致、底层可寻址。遇到 struct 字段里的指针、map 或嵌套 []T，它直接不处理——不是“没深拷贝”，而是“压根没进那层”。常见错误是传入一个含指针的结构体切片，结果所有副本仍指向同一块内存，改一个全变。
更关键的是：reflect.Copy 不分配新内存，只是 memmove 的反射封装。你得自己用 reflect.MakeSlice、reflect.New 或 reflect.MakeMap 先建新容器，再往里填。
手动递归实现时必须检查三类字段
漏掉任意一类，轻则 panic，重则静默共享数据：
-
nil指针：调.Elem()前不检查.IsNil()，直接 panic；正确做法是先reflect.New(t.Elem())，再递归拷贝其.Elem() - 未导出字段（小写开头）：
.CanSet() === false，强行.Set()必 panic；反射只能读，不能写，这类字段默认跳过，别硬塞 - 接口值（
interface{}）：.Kind()是reflect.Interface，但它的.Elem()才是真实值；只复制壳子，不递归处理.Elem()，结果就是一堆nil或零值
切片和 map 的“伪深拷贝”陷阱
只调 reflect.MakeSlice(t, v.Len(), v.Cap()) 或 reflect.MakeMap(t) 是不够的：
- 切片：新切片底层数组仍是共享的，必须逐个
v.Index(i).Set(...)，且每个元素都要递归深拷贝 - map：必须遍历
v.MapKeys()，对每个 key 和 value 分别深拷贝后，再用.SetMapIndex()写入新 map；漏掉任意 key/value，那个 entry 就还是原引用 - 注意
reflect.ValueOf(&x).Elem()和reflect.ValueOf(x)的区别：深拷贝一般传值进去，靠返回新reflect.Value，不是为了改原值
性能开销比你想象中高
一次中等复杂结构体的反射深拷贝，比手写 Clone() 方法慢 5–20 倍，原因很实在：
- 每次
reflect.New()、reflect.MakeSlice()都是堆分配，触发 GC 压力 - 反射要维护类型元数据、字段名字符串、方法表等额外内存，不是纯数据拷贝
- 不支持
func、unsafe.Pointer、含sync.Mutex的结构体，遇到直接 panic，得提前用v.Kind() == reflect.Func检查
高频场景（如 HTTP 中间件、gRPC 请求封装）慎用；真要通用，优先考虑结构体自定义 DeepCopy() 方法，或用 encoding/gob 序列化兜底——虽然慢，但语义清晰、边界可控。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
