Go反射性能衰退无法根治，只能通过规避、缓存或提前生成绕开；reflect.Value.Call因重复校验与装包慢10–100倍；热路径禁用，优先缓存函数指针；FieldByName是性能黑洞，应预计算索引映射或用Field(i)；go:generate可将反射移至构建期提升数量级性能。
Go反射导致的性能衰退无法靠“优化反射代码”根治，只能通过规避、缓存或提前生成来绕开运行时开销。
reflect.Value.Call 为什么慢得离谱
每次调用 reflect.Value.Call 都要重做编译期已知的事：校验参数类型、分配临时切片装 reflect.Value、拆包接口、跳转函数指针、再打包返回值。实测空函数直调约 2 ns，而 reflect.Value.Call 通常在 20–200 ns，慢 10–100 倍。
- 别在热路径（如 HTTP handler 内部、高频循环）里用
Call，哪怕只调一次 - 如果必须动态调用，把目标方法提前转成闭包或函数指针缓存，比如
fn := v.Method(0).Func，后续直接fn.Call(args) - 注意：
MethodByName本身也有哈希查找开销，不如Method(i)稳定，但需确保方法顺序不变
FieldByName 是结构体反射的性能黑洞
reflect.Value.FieldByName 在字段多时是线性搜索，每查一次都要字符串比对。一个 20 字段的 struct，平均要比较 10 次才能命中。
- 优先用
v.Field(i)，配合注释说明索引含义，比如// Name at index 0 - 字段名稳定时，启动时预计算字段名→索引映射，存进
sync.Map，后续查表 O(1) - 避免缓存
reflect.Value实例（含具体数据），只缓存reflect.Type和字段偏移数组[]int - 字段偏移数组比缓存整个
reflect.StructField更轻量，也更利于 GC
用 go:generate 替代运行时反射
90% 的“通用序列化/ORM/绑定”场景，类型集合其实是静态的。把反射逻辑从运行时搬到构建阶段，性能差距是数量级的。
立即学习“go语言免费学习笔记（深入）”；
- 为每个关键 struct 生成专用的
ToMap()、FromMap()或UnmarshalJSON() - CI 中必须校验：执行
go generate后git diff --quiet，不通过就失败 - 生成函数签名要与标准库一致（如接收
*T，返回error），便于无缝替换 - 慎用
unsafe.Offsetof手写 getter/setter——快但脆弱，字段增删或 build tag 变动都会 silent fail
真正难处理的是那些无法预知类型的场景：deep copy 任意 struct、调试时 dump interface{}、插件系统加载未知类型。这些地方反射是刚性需求，只能接受代价，并严格限制调用频次和输入规模——比如只在 debug 模式启用，或加采样率控制。
