Go语言struct赋值默认是浅拷贝，仅引用类型字段共享底层数据；copier.Copy默认也是字段级浅拷贝，深拷贝需手动实现或显式启用选项，并须依据业务语义精准控制。
Go 语言没有内置的深拷贝机制，copier 库只是众多手动/反射方案之一，它不解决根本问题——真正决定要不要深拷贝、怎么拷贝的，是你对字段语义的理解，而不是库本身。
struct 赋值默认是浅拷贝，但“浅”只对引用类型字段生效
很多人误以为 copy := original 是“全浅”，其实不是：值类型字段（int、string、不含引用字段的嵌套 struct）会被完整复制；只有 []T、map[K]V、*T、chan、func 这类引用类型字段才共享底层数据。
常见错误现象：
- 改
copy.Scores[0] = 99，original.Scores[0]也变成 99 - 改
copy.Config.Timeout = 30，original.Config.Timeout同步变化（因为Config是指针）
使用场景：
立即学习“go语言免费学习笔记（深入）”；
- 临时读取、只读传递时，浅拷贝完全够用，性能好、开销低
- 需要并发修改或状态隔离时，必须识别哪些字段是引用类型，并针对性处理
copier.Copy 是基于反射的通用拷贝，不是深拷贝保证
copier.Copy 默认行为是字段级浅拷贝：它会递归遍历结构体字段，但对 []T、map、*T 等仍只复制地址，除非显式启用深拷贝选项（如 copier.CopyWithOption 配合 copier.OptionDeepCopy），且该选项仅对部分类型生效（比如切片和 map，但对嵌套指针里的指针不一定递归）。
容易踩的坑：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 依赖
copier.Copy默认行为以为“自动深拷贝”，结果运行时出现意外交互 - 字段名大小写不一致或 tag 标注错误（如
json:"name"但结构体字段叫UserName），导致字段被跳过 - 未导出字段（小写首字母）永远不被
copier访问，哪怕你写了copier的自定义映射规则
参数差异：
-
copier.Copy(dst, src)：最简调用，纯字段名匹配 + 浅拷贝 -
copier.CopyWithOption(dst, src, copier.OptionDeepCopy)：对切片、map 做底层数组/哈希表复制，但对*Detail字段仍只复制指针地址
真正可控的深拷贝必须手动实现或明确序列化边界
手动实现适合字段稳定、嵌套不深的结构体，能精确控制每个引用字段的复制逻辑，避免反射开销和不确定性。
实操建议：
- 切片：
dst.Slice = make([]T, len(src.Slice)); copy(dst.Slice, src.Slice) - map：
dst.Map = make(map[K]V); for k, v := range src.Map { dst.Map[k] = v }（若V是引用类型，需再递归） - 指针：
if src.Ptr != nil { dst.Ptr = &(*src.Ptr) }（前提是*src.Ptr本身不含需深拷贝的引用字段） - 嵌套结构体：逐字段判断，值类型直赋，引用类型走对应逻辑
序列化方式（如 json.Marshal/Unmarshal 或 gob）看似简单，但有隐含限制：
- 未导出字段丢失（
json默认忽略小写字段） -
chan、func、unsafe.Pointer无法序列化，会 panic 或静默跳过 - 性能差：涉及内存分配、编码解析，不适合高频调用
第三方库如 deepcopy 或 go-deepcopy 并不比手动更“安全”
这些库本质仍是反射+递归，它们能覆盖更多类型组合，但无法绕过 Go 的语言限制：未导出字段不可访问、func 和 chan 无法安全复制、循环引用会 panic。更重要的是，它们无法理解你的业务语义——比如某个 *Cache 字段本就不该复制，而应复用单例。
容易被忽略的地方：
- 深拷贝不是银弹：复制一个含 10MB 切片的结构体，会立刻多占 10MB 内存
- 并发场景下，如果原对象正在被其他 goroutine 修改，深拷贝过程本身可能读到中间态数据（无锁前提下）
- “深”的程度由你定义：是否要复制
http.Client？是否要复制sync.Mutex？这些都得人工判断
