reflect.TypeOf 和 reflect.ValueOf 每次调用都慢，因需运行时查哈希表、构造新对象、接口转换及内存分配；FieldByName 是 O(n) 线性搜索；MethodByName+Call 经三重间接且无法内联；缓存应按 reflect.Type 维度存储字段索引映射，避免缓存 reflect.Value。
reflect.TypeOf 和 reflect.ValueOf 为什么每次调用都慢
因为它们不是“查缓存”，而是每次都在运行时查类型系统哈希表、构造新对象、做接口转换。Go 的类型描述符（reflect.Type 和 reflect.Value）不是单例，重复调用 reflect.TypeOf(x) 就等于重复走一遍类型解析全流程。
- 每次调用都触发哈希查找 + 接口装箱 + 内存分配（
reflect.Value占约 96 字节） - 编译器无法内联这些调用，也做不了逃逸分析优化
- 高频场景（如 HTTP 请求中每请求反射一次结构体）会迅速拉高 GC 压力和 CPU 使用率
FieldByName 为什么比直接访问字段慢几十倍
它本质是线性搜索：遍历结构体所有字段名字符串，逐个 == 比较。字段越多、名字越长，越慢；而且无法利用 CPU 预取或分支预测。
- 对比
v.FieldByName("Name")（O(n)）和v.Field(0)（O(1)），后者快一个数量级 - 即使只查一次，也要走完整字段遍历逻辑，不能跳过已知偏移
- 真实项目中，ORM 或序列化库若在循环里反复
FieldByName，很容易成为 P99 延迟瓶颈
MethodByName + Call 为什么几乎无法优化
反射调用方法要经过三重间接：先字符串查方法表 → 校验参数类型与数量 → 构造 []reflect.Value 切片 → 最终进 reflect.Value.Call 的通用分派逻辑。整个过程绕过了所有编译期绑定。
-
reflect.Value.Call无法被内联，且每次都要复制参数切片（堆分配） - 没有调用栈折叠，调试时看到的堆栈全是
reflect.*，掩盖真实业务路径 - 哪怕方法本身只有 1 行赋值，反射调用开销也可能占到总耗时的 95% 以上
缓存反射结果真的有用吗？怎么缓存才安全
非常有用——但必须按 reflect.Type 缓存，而不是按结构体变量地址或字符串名。缓存错维度，等于没缓存。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map存map[reflect.Type]map[string]int，把字段名映射为索引，首次解析后永久复用 - 不要缓存
reflect.Value实例（它包含指向原值的指针，生命周期难控，易导致意外修改或 panic） - 避免在
init()里预热全部类型——按需加载，否则启动慢、内存占用高
var fieldIndexCache sync.Map // key: reflect.Type, value: map[string]int
func getFieldIndex(t reflect.Type, name string) int {
if cached, ok := fieldIndexCache.Load(t); ok {
return cached.(map[string]int)[name]
}
indexMap := make(map[string]int)
for i := 0; i < t.NumField(); i++ {
indexMap[t.Field(i).Name] = i
}
fieldIndexCache.Store(t, indexMap)
return indexMap[name]
}
真正容易被忽略的是：缓存键必须是 reflect.Type 本身，而非 t.String() 或 t.Name() ——匿名结构体、泛型实例化后的类型名可能相同，但 reflect.Type 是唯一标识。
