高频反射调用必须将运行时查找转为编译期或初始化期确定性操作，否则每秒万次FieldByName/MethodByName将显著消耗CPU并加剧GC压力；应缓存reflect.Type和字段索引映射，避免缓存reflect.Value，优先使用Field(i)或预计算Offset，并懒构造缓存以提升稳定性与性能。
高频反射调用不能靠“少用点”来优化，必须把运行时查找变成编译期或初始化期的确定性操作。 否则每秒万次 FieldByName 或 MethodByName 会吃掉可观 CPU，且 GC 分配量直线上升。
缓存 reflect.Type 和字段索引映射，别缓存 reflect.Value
每次调用 reflect.TypeOf(x) 都要解析类型、分配结构体；reflect.ValueOf(x) 更是每次新建实例，无法比较、不可当 map key。但 reflect.Type 对同一类型返回的是同一地址，只读且并发安全。
- 正确 key：用
uintptr(unsafe.Pointer(t))，零开销、不依赖包路径，标准库（如encoding/json）也这么干 - 错误 key：
map[interface{}]T（接口值包含动态指针，无法命中）、map[string]T（t.String()字符串分配 + 哈希，匿名 struct 还会失效） - 字段访问缓存重点不是字段本身，而是 “字段名 → 索引” 或 “字段名 → 偏移量”。例如预计算
nameIndex := t.FieldByName("Name").Index，后续直接v.Field(nameIndex) - 别把
reflect.Value.Field(i)结果缓存——它绑定具体实例，没法复用
FieldByName 是性能黑洞，优先用 Field(i) 或预计算 Offset
FieldByName 在字段多时是纯线性扫描：20 字段平均比对 10 次，100 字段就是 100 次字符串比较。而 Field(i) 是数组下标访问，常数时间。
- 启动时一次性遍历
t.NumField()，构建map[string]int映射，存在普通map+sync.Once初始化的全局表里（别用sync.Map，读多写少反而更慢） - 更激进的做法：用
unsafe.Offsetof(User{}.Name)算出偏移，封装成闭包，运行时只剩指针运算和类型转换，GC 分配趋近于零 - 注意脆弱点：字段增删、顺序调整、
//go:notinheap标记、甚至 build tag 变动都可能让 offset 失效，需配套 CI 校验（比如go generate后git diff --quiet）
Method.Call 开销占比超 80%，缓存 Method 不如缓存 Func
reflect.Value.MethodByName("Save").Call(args) 的耗时里，MethodByName 只占 15–20%；真正重头是 Call：参数校验、栈帧重建、接口拆包、汇编跳转，空方法压测都在 80–120 ns，而直调仅约 1.2 ns。
立即学习“go语言免费学习笔记（深入）”；
- 缓存
reflect.Method或reflect.Value实例意义不大——Call开销没省多少 - 真正该缓存的是
reflect.Method.Func返回的reflect.Value，它对应底层函数指针，可安全复用 - 签名固定时（如所有 handler 都是
func(context.Context) error），用reflect.MakeFunc在初始化阶段生成闭包，后续调用等价于普通函数调用，零反射开销 - 避免在 HTTP handler 或高频循环里出现
Call，哪怕只调一次——热路径上它就是吞吐量杀手
最易被忽略的是“按需加载”：别在 init() 里预热所有可能用到的类型，内存浪费且无意义；缓存应懒构造，首次访问时计算并存入，后续直接命中。字段偏移、方法索引、序列化闭包……这些都不是越早算越好，而是越晚算、越贴近真实使用场景，越稳。
