go标准库未提供reflect.deepcopy，因其语义无法自动定义：指针解引用、sync.mutex复制、循环引用处理等必须人工决策；依赖json.marshal/unmarshal是伪深拷贝，存在语义变更、精度丢失、副作用及性能更差等问题；真正优化在于减少内存分配、用uintptr映射检测循环引用、跳过未导出字段、避免无谓reflect.value构造；第三方代码生成方案（如ulule/deepcopier）因编译期展开、零反射开销、编译期校验而显著更快。
为什么 reflect.DeepCopy 不存在且不能靠它优化
Go 标准库压根没提供 reflect.DeepCopy，这不是性能问题，而是语义不可自动定义：指针要不要解引用？sync.Mutex 能不能复制？循环引用怎么断？这些都得你拍板。想“优化”一个根本不存在的函数，等于在文档里找编译器报错——方向就错了。
避免 json.Marshal/Unmarshal 这类伪深拷贝
它看起来快（尤其小结构体），但实际是重建而非拷贝：
-
nilslice 变成[]int{}，语义已变 -
time.Time经序列化可能丢失纳秒精度或时区信息 - 自定义
UnmarshalJSON方法可能触发副作用（比如重置内部状态） -
func、unsafe.Pointer、chan全被静默丢弃 - 性能上，大结构体序列化+反序列化比纯反射递归慢 5–10 倍
真正有效的性能优化点只有三个
手动实现反射深拷贝时，瓶颈不在遍历逻辑，而在内存分配和地址检查：
- 用
map[uintptr]bool记录已访问对象地址，比map[reflect.Value]bool快且稳定——后者每次调用reflect.ValueOf()都生成新实例，无法做键 - 对切片、map、指针值，只在首次进入时调用
v.UnsafeAddr()并检查v.CanAddr()；漏掉这个判断，遇到字面量取地址会 panic，而不是慢 - 基础类型（
int、string、bool）直接Set()，别封装成递归调用；结构体字段遍历时跳过未导出字段，省掉无效CanSet()判断
第三方库比手写反射更快的根本原因
像 ulule/deepcopier 这类主流方案不靠运行时反射，而是用代码生成器在编译期展开字段复制逻辑：
- 零反射开销，无
reflect.Value构造/拆包成本 - 字段名和类型匹配在编译期校验，运行时报错变编译报错
- 支持
field:tag 映射、skip忽略、条件复制等，语义更可控 - 如果你的结构体类型固定、变更不频繁，生成代码比通用反射快一个数量级
循环引用检测和指针解引用这两步，手写时只要漏掉任意一个，上线后不是报错，而是卡死或静默数据污染——这种 bug 比慢更难排查。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
