Go反射性能差是运行时必然开销，reflect.ValueOf频繁堆分配、reflect.Value.Call校验开销大；应缓存reflect.Value、预分配参数切片、用unsafe.Offsetof零拷贝或代码生成优化。
Go反射性能差不是“写法问题”，而是运行时必然开销；不优化就用，线上压测时CPU profile里reflect.ValueOf和reflect.Value.Call大概率排前三。
为什么reflect.ValueOf会频繁堆分配
每次调用reflect.ValueOf，Go都要构造一个reflect.Value结构体，它内部含unsafe.Pointer、类型标志位、对齐字段等，编译器几乎无法证明它不逃逸。实测中，对struct{ Name string }反复调用reflect.ValueOf，每调用一次就触发一次小对象堆分配——高频场景下GC压力直线上升。
常见错误现象：json.Unmarshal里每解一个字段都重新reflect.ValueOf(v)，或在HTTP中间件循环里对每个请求参数做reflect.ValueOf。
- 正确做法：把
reflect.ValueOf移到初始化阶段，例如全局缓存reflect.Value（注意不是reflect.Type） - 别缓存
reflect.ValueOf(&x)这种指针的指针，Call()会panic - 如果目标是结构体字段遍历，优先缓存
reflect.Type+ 字段索引数组，避免每次Field(i)都查表
reflect.Value.Call慢在哪，怎么绕过
reflect.Value.Call比直接调用慢25–40ns（空函数），因为要逐个校验参数reflect.Type、复制到内部切片、触发runtime.callDeferred间接跳转，并完全绕过内联和逃逸分析。
立即学习“go语言免费学习笔记（深入）”；
使用场景：通用RPC服务端分发、校验器钩子、插件式回调。
- 必须提前缓存
reflect.Value：只对函数字面量（如handleUser）调用一次reflect.ValueOf，之后复用 - 避免在循环中重建
[]reflect.Value：预分配固定长度切片，每次用slice[:0]清空复用 - 别把它放进hot path：比如路由匹配后立刻
Call，应改为预注册+直接调用函数指针
零拷贝反射：用unsafe.Offsetof替代字段遍历
当目标结构体固定、字段名/顺序已知（如ORM模型、JSON DTO），用unsafe.Offsetof加unsafe.Pointer直接取字段，能彻底跳过reflect.Type.Field查找和reflect.Value.Field封装，实测提速5–6倍。
适用条件：结构体不能有嵌入字段、不能含接口或map/slice等需深度反射的类型；必须导出字段（首字母大写）。
- 示例：获取
User.Name偏移量：offset := unsafe.Offsetof(User{}.Name) - 取值时：
namePtr := (*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&u)) + offset)) - 风险点：结构体字段顺序变更、加字段、改tag会导致偏移错乱，必须配合单元测试校验
缓存+代码生成：什么时候该放弃反射
如果类型组合有限（如只有User、Order、Product三类结构体参与序列化），硬编码或用go:generate生成专用函数，性能接近原生访问，且无运行时开销。
对比数据：对10万次User序列化，纯反射耗时约180ms，缓存Type+Value降到65ms，零拷贝方案32ms，代码生成仅9ms。
- 推荐工具：
easyjson（JSON）、msgp（MessagePack）、自定义genny模板 - 注意：生成代码需纳入CI检查，避免结构体变更后未重生成
- 真正难优化的是“任意类型”场景（如
interface{}泛型前的老ORM），这时缓存和零拷贝仍是主力
最容易被忽略的一点：reflect.Value本身不是线程安全的——你不能跨goroutine复用同一个reflect.Value实例，但可以安全复用它封装的调用逻辑（如callFn结构体）。这点在并发中间件里踩坑最多。
