copy函数仅浅拷贝，对指针、map、slice等引用类型只复制地址；修改新切片的嵌套结构会影响原切片，适用场景限于基本类型或无引用字段的struct。
copy 函数只能浅拷贝，别指望它复制嵌套结构
Go 的 copy 函数只复制元素值，对指针、map、slice、chan 等引用类型，拷贝的是地址本身。如果原切片元素是 []int 或 map[string]int，用 copy 得到的新切片里，每个元素仍指向同一底层数据。
常见错误现象：copy 后修改新切片的某个子切片，原切片对应位置也跟着变；或者深一层的 map 被意外共享导致并发写 panic。
- 适用场景：仅当切片元素是基本类型（
int、string、struct{}且不含引用字段）时，copy才等价于“安全拷贝” - 参数差异：
copy(dst, src)要求dst容量足够，否则截断；不检查元素内部是否可复制 - 性能影响：快，纯内存搬运；但掩盖了逻辑上的共享风险
手动实现 slice 深拷贝的三种典型方式
没有银弹，选哪种取决于元素类型和性能敏感度。别直接上 json.Marshal/Unmarshal——它慢、不能处理未导出字段、还会丢掉方法和 channel。
- 元素是基本类型或纯值 struct：用
make+copy即可，例如newS := make([]T, len(oldS)); copy(newS, oldS) - 元素含 slice/map/pointer：逐层递归复制，例如
[]map[string][]int需先make外层，再对每个map做for k, v := range oldMap { newMap[k] = append([]int(nil), v...) } - 需要通用性且接受开销：用
gob编码解码（比 json 更 Go-native，支持 unexported 字段），但要求类型可注册，且不能含func或unsafe.Pointer
切片扩容机制如何干扰深拷贝逻辑
Go 切片扩容不是简单翻倍。当容量 append 动态构造一个“深拷贝”，底层底层数组可能被意外复用。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：两个看似独立的切片，在多次 append 后突然共享底层数组，改一个另一个也变——尤其发生在从同一源切片反复 append 不同副本时。
- 关键点：
append返回的新切片，其底层数组可能和原切片相同（只要容量够） - 规避方法：强制分配新底层数组，例如
newS := append(oldS[:0:0], oldS...)，利用oldS[:0:0]截断容量为 0，迫使append分配新空间 - 兼容性注意：该技巧在 Go 1.21+ 安全，但若元素含指针且你依赖 GC 及时回收旧底层数组，扩容行为变化可能影响内存驻留时间
为什么不要用 reflect.DeepCopy 做生产环境深拷贝
reflect 包确实能通用深拷贝任意值，但它在运行时做大量类型检查和动态分配，性能差、不可控、还容易 panic（比如遇到 func 或 unsafe 类型）。
实际项目里，真正需要深拷贝的结构往往固定且有限。硬上 reflect 会把简单问题复杂化，还埋下维护雷。
- 错误信息示例：
panic: reflect.Value.Interface: cannot return value obtained from unexported field or method - 使用场景仅限 debug 工具或测试辅助；生产代码中应为关键结构显式编写
Clone()方法 - 性能影响：比手写拷贝慢 10–100 倍，GC 压力显著升高，尤其在高频调用路径上
深拷贝真正的复杂点不在语法，而在厘清“哪些字段必须隔离”“哪些可以共享”。比如一个带缓存的 struct，缓存字段通常不该深拷，而数据字段必须。这点容易被忽略，一上来就全量复制，反而引入 bug 和性能陷阱。
