根本原因是每次反射复制都触发元数据解析、安全校验和类型转换三重开销，无法内联且解释执行；实测10字段结构体直接赋值8ns，反射复制420ns，慢50倍以上。
为什么结构体反射复制比直接赋值慢几十倍
根本原因不是“用了反射”，而是每次复制都触发完整元数据解析+安全校验+类型转换三重开销。比如 reflect.ValueOf(src).Field(i) 每次都要查字段偏移、验证可访问性、生成新 reflect.Value 实例——这些动作无法被 JIT 内联，只能解释执行。
实测显示：10 字段结构体的直接赋值约 8 ns；用 reflect.Copy 或手写循环调用 Field(i).Set() 平均耗时 420 ns，慢 50 倍以上。
- 字段数量越多，
NumField()遍历和Field(i)查找的累积开销越明显 - 嵌套结构体或指针字段会额外触发
Elem()和Indirect()，每层多一次地址解引用和空值检查 - 如果字段含 interface{} 或泛型类型，
reflect.Value.Convert()会强制分配新对象，引发 GC 压力
缓存什么才真正减少开销
缓存 reflect.Type 或 reflect.Value 本身没用——前者是只读单例，后者每次调用都新建且不可复用。真正该缓存的是字段访问路径和方法句柄。
- 缓存字段索引映射：
map[reflect.Type]map[string]int，避免每次FieldByName()字符串匹配 - 缓存
reflect.StructField切片（非reflect.Value），它不绑定实例，可跨对象复用 - 对固定结构体，预生成
reflect.Method（如lookup.FindStructField()）并存入sync.Map，跳过运行时查找 - 不要缓存
reflect.ValueOf(&src).Field(i)的结果——它的地址随 src 实例变化，无法复用
Go 1.14+ 下绕过反射复制的可行路径
当结构体类型固定、字段稳定时，直接计算内存偏移比反射快一个数量级。Go 运行时 abi.Type 布局自 1.14 起已稳定（x86_64 下 48 字节头 + 字段表），可安全读取。
- 用
unsafe.Offsetof获取源/目标字段偏移，按字节 memcpy（需确保对齐和大小一致） - 通过
(*abi.Type)(unsafe.Pointer(t)).PtrBytes判断是否含指针，决定是否需要保留 GC 可达性 - 生成闭包函数封装复制逻辑：
func(dst, src unsafe.Pointer)，运行时零反射开销 - 注意：该方式绕过类型系统，若字段增删或签名变更，编译不报错但运行时 panic
最容易被忽略的性能点：别在热路径上做反射复制
哪怕你缓存了所有元数据，只要还在请求处理循环里调用 reflect.Value.Set()，就逃不开 receiver 可寻址性校验和参数转换这两步——它们占整个反射复制耗时的 70% 以上。
更现实的做法是：对高频结构体（如 HTTP 请求/响应体、DB 记录），用 //go:generate 提前生成 CopyTo() 方法；只对真正动态的场景（如通用配置加载器）保留反射兜底。
