reflect.ValueOf在循环中性能差因每次分配96字节实例并触发GC，且FieldByName需线性字符串比对；应预缓存reflect.Type及字段索引，用FieldByIndex替代FieldByName，禁用热路径的Call和FieldByName。
为什么reflect.ValueOf在循环里特别伤性能
每次调用 reflect.ValueOf 都会分配新的 reflect.Value 实例（约96字节），触发 GC；更关键的是，FieldByName 是线性遍历字段名做字符串比对，10个字段就要比10次，100个字段就是100次——这在高频循环中直接拖垮吞吐量。
- 别写
for _, item := range items { v := reflect.ValueOf(item); v.FieldByName("ID").Int() } - 把
reflect.TypeOf和字段索引预计算好，缓存到map或结构体里 - 用
FieldByIndex替代FieldByName，索引查表是 O(1)
缓存reflect.Type比缓存reflect.Value更安全也更轻量
reflect.Type 是只读、并发安全的，同一类型的 reflect.TypeOf(x) 返回值指针恒定；而 reflect.Value 每次都新建实例，含具体数据，无法复用，还带逃逸和 GC 压力。
- 正确缓存方式：用
map[reflect.Type]map[string]int存字段名→索引映射，key 是reflect.Type本身（可直接作 map key） - 错误方式：用
map[interface{}]T或map[string]T（Type.String()触发字符串分配） - 启动时或首次访问时预热缓存，别等到请求来了再算
避免在热路径调用reflect.Value.Call和FieldByName
reflect.Value.Call 每次都要重做编译期已知的事：校验参数类型、分配临时切片装 reflect.Value、拆包接口、跳转函数指针、再打包返回值。实测空函数直调约2 ns，而 reflect.Value.Call 通常在20–200 ns，慢 10–100 倍。
- HTTP handler、高频循环、日志采集等热路径禁用
Call和FieldByName - 必须动态调用时，提前缓存
v.Method(i).Func得到函数指针，后续直接调用 - 字段访问优先用
v.Field(i)，配合注释说明索引含义，比如// Name at index 0
真正难处理的是无法预知类型的场景
deep copy 任意 struct、调试时 dump interface{}、插件系统加载未知类型——这些地方反射是刚性需求，只能接受代价，并严格限制调用频次和输入规模。
立即学习“go语言免费学习笔记（深入）”；
- 只在 debug 模式启用 dump 逻辑
- 加采样率控制，比如每千次请求只反射分析 1 次
- 对输入 struct 深度设硬上限（如
maxDepth=5），超限直接返回 error 而非 panic
字段偏移数组比缓存整个 reflect.StructField 更轻量，也更利于 GC；但一旦你开始手写 unsafe.Offsetof，就得承担字段增删或 build tag 变动导致 silent fail 的风险。
