copy函数只做浅拷贝，对指针、map、slice等类型仅复制引用；深拷贝需手动实现Clone方法或逐层处理；reflect.DeepEqual可验证值相等性，但需配合修改测试确认内存独立性。
copy 函数只能做浅拷贝，别指望它复制嵌套结构
Go 的 copy 函数本质是内存块复制，对切片元素逐字节搬运。如果切片元素是基础类型（int、string、[3]int），没问题；但一旦元素是指针、map、slice、chan 或 struct 里含这些类型，copy 只复制指针值，不复制它们指向的内容。
常见错误现象：copy 后修改新切片里的 map 元素，原切片对应位置的 map 也跟着变 —— 这不是 bug，是预期行为。
- 使用场景：快速复制字节流、字符串切片、纯值类型 slice（如
[]int） - 参数差异：
copy(dst, src)要求dst长度 ≥src长度才安全；若dst更短，只复制前len(dst)个元素 - 性能影响：极快，底层调用 memmove；但对含指针的结构，省下的时间可能换来后续难以调试的并发或修改副作用
深拷贝必须手动处理，标准库不提供通用方案
Go 没有类似 Python 的 deepcopy 或 Java 的序列化自动深拷贝机制。是否需要深拷贝、怎么深拷贝，完全取决于你的数据结构形状和语义。
常见错误现象：用 json.Marshal + json.Unmarshal 做“深拷贝”，结果丢失方法、channel、func 字段，或 panic 于 unexported 字段 —— 它只是序列化/反序列化，不是深拷贝原语。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 推荐做法：为自定义类型实现
Clone()方法，显式控制每个字段行为（比如对map用for k, v := range oldMap { newMap[k] = v }） - struct 含 slice/map 时，不能只
copy(dstSlice, srcSlice)，得先 make 新底层数组，再逐项赋值或递归 clone - 性能影响：深拷贝必然带来分配和遍历开销；如果结构很深或很大，要考虑是否真需要拷贝，还是改用不可变设计或共享+读锁
用 reflect.DeepEqual 判断是否“真正独立”比猜更可靠
你写了拷贝逻辑，但不确定是不是深的？别靠肉眼检查，用 reflect.DeepEqual 验证结果。
注意：它只比较值相等性，不反映内存独立性。所以要配合“改后不联动”测试 —— 修改副本后，用 reflect.DeepEqual 确认原数据没变，再改原数据，确认副本仍不变。
- 典型误用：对含
func或unsafe.Pointer的结构调用reflect.DeepEqual会 panic - 兼容性影响：
reflect.DeepEqual对nilslice 和len==0slice 视为相等，但它们底层指针可能不同 —— 这在判断“是否共享底层数组”时不够用 - 更准的做法：对 slice，用
unsafe.SliceData（Go 1.20+）或reflect.Value.UnsafeAddr比较底层数组地址
底层数组共享是常态，不是缺陷
Go 切片的“引用语义”来自其三元组（ptr, len, cap）。copy、切片截取（s[1:3]）、append 在未扩容时都可能复用同一底层数组。这不是 bug，是设计使然 —— 它让操作廉价，但也要求开发者主动管理所有权边界。
容易被忽略的地方：即使你用 make([]T, len(s)) 分配新空间并 copy，只要元素是 map/slice/ptr，它们内部仍可能共享；真正的隔离必须穿透到最深层可变值。
