copy函数只做浅拷贝，复制切片头及元素值，但对指针、map、嵌套slice等仅复制引用，导致底层数组或哈希表共享，无法解决并发安全问题，深拷贝需手动逐层处理。
copy 函数只做浅拷贝，它不处理并发安全问题，也不递归复制嵌套引用；所谓“深拷贝”必须手动实现，且深拷贝本身不能自动解决并发读写冲突。
copy 函数到底复制了什么
它按元素逐个赋值，对 []int、[]string 这类纯值类型切片是完整复制；但一旦元素含 *T、map、[]byte、struct{ Data []int } 等，copy 只复制指针或 header，底层数组/哈希表仍共享。
- 常见错误现象：
src := []map[string]int{{"a": 1}}; dst := make([]map[string]int, 1); copy(dst, src)后，修改dst[0]["a"] = 99，src[0]["a"]也变成 99 - 使用场景：适合字节流搬运、参数透传、临时缓存等不需要隔离修改的场合
- 参数差异：
copy(dst, src)实际复制数恒为min(len(dst), len(src))，与底层数组是否重叠无关 - 性能影响：极快，但掩盖了后续因共享导致的并发 panic（比如两个 goroutine 同时写同一个 map）
为什么 copy 不能用于并发安全的副本构造
并发安全不是靠“复制一次”就能解决的。即使你用 copy 得到一个新切片头，只要其中元素仍指向共享的 map 或 slice，多个 goroutine 对这些嵌套结构的读写就依然可能冲突。
- 典型误用：在 handler 中
copy(req.Params, r.URL.Query())，以为得到独立参数副本，结果多个请求共用同一底层map[string][]string，引发fatal error: concurrent map writes - 真正需要的是“数据隔离”，而非“切片头隔离”——得把每个
map、每个子slice都重新make并逐项复制 - 没有银弹：标准库不提供带并发语义的拷贝函数；
sync.Map是另一种思路，但它是线程安全容器，不是拷贝工具
手动深拷贝时必须检查的三个层级
判断是否需深拷贝，不能只看切片本身，而要穿透到字段级。以下三类结构一旦出现在元素中，copy 就失效：
立即学习“go语言免费学习笔记（深入）”；
-
map[K]V：必须newMap := make(map[K]V); for k, v := range oldMap { newMap[k] = v }（注意v本身若为引用类型，还需继续深拷） -
[]T（其中T含引用字段）：不能只copy(newSlice, oldSlice)，得先make外层，再对每个T字段分别深拷（例如newSlice[i].Data = append([]byte(nil), oldSlice[i].Data...)） -
*T：必须newPtr := &T{}; *newPtr = *oldPtr，且若T内还有引用字段，继续递归
漏掉任意一层，都可能在压测时突然出现数据错乱或 panic。
reflect.DeepEqual 只能验证值等价，不能代替内存分析
你写完深拷贝逻辑后，用 reflect.DeepEqual 确认副本和原数据“值相等”只是第一步；更要验证“改后不联动”：
- 修改副本中某
map的键值，确认原数据对应位置不变 - 再修改原数据中同一位置，确认副本不受影响
- 注意边界：
reflect.DeepEqual对nilslice 和len==0slice 返回true，但它们底层数组指针可能不同——这时得用unsafe.SliceHeader（仅限调试）比对地址
真正容易被忽略的，是结构体字段里那些未导出的 sync.Mutex 或 chan：它们无法被 json 或 gob 拷贝，手动深拷时若忘记跳过或置零，运行时可能 panic 或死锁。
