Go反射开销大，无法优化至原生级别；应规避反射、缓存类型元信息或用代码生成替代。reflect.Value.Call慢10–100倍因每次需类型检查、切片分配、接口拆包等；字段访问优先Field(i)而非FieldByName；sync.Map缓存字段偏移数组；go:generate生成静态代码更优；仅低频场景如deep-copy、调试、插件系统才用反射。
Go 的反射（reflect）本身开销大，无法“优化”到和原生代码同级；真正可行的是**规避反射、缓存反射结果、或用代码生成替代运行时反射**。
为什么 reflect.Value.Call 比直接调用慢 10–100 倍
每次调用 reflect.Value.Call 都要：检查参数类型匹配、分配临时切片装 reflect.Value、做接口值拆包、跳转到函数指针、再重新打包返回值。这些在编译期已知的逻辑，运行时全得重做。
- 实测：空函数直调耗时 ~2 ns；用
reflect.Value.Call调同等函数，通常 20–200 ns - 结构体字段访问也类似：
v.FieldByName("Name")每次都要哈希查找字段名字符串，而v.Field(0)快得多但不安全 - 只要字段顺序/名称稳定，优先用
Field(i)+ 注释说明索引含义，而非FieldByName
用 sync.Map 缓存 reflect.Type 和 reflect.Value 的常见组合
反复对同一类型做反射操作（如 JSON 序列化、ORM 字段映射）时，reflect.TypeOf(x) 和 reflect.ValueOf(x) 本身不贵，但后续的 .MethodByName 或 .FieldByName 是热点。
- 缓存
reflect.Type对应的字段偏移数组（[]int）比缓存reflect.StructField更轻量 - 对常用类型预热：启动时调用一次
getStructInfo(reflect.TypeOf(MyStruct{}))，把字段名→索引映射存进sync.Map - 避免缓存
reflect.Value实例（它包含具体数据，不可复用），只缓存类型层面的元信息
用 go:generate + stringer 或自定义模板生成反射替代代码
90% 的“需要反射”的场景，其实类型集合是有限且静态的（比如 HTTP handler 参数绑定、gRPC message 转 map）。这时生成代码比运行时反射更稳更快。
