MethodByName 每次调用都执行哈希+线性遍历，性能差；应预缓存 reflect.Type.Method(i) 索引或用字段偏移直访，但需确保类型稳定、字段/方法顺序不变。
MethodByName 每次调用都做哈希+线性遍历
reflect.Value.MethodByName("Save") 不是查一张静态表，而是每次执行时：先对字符串做哈希，再在类型的方法列表里线性比对名字——哪怕你反复调用同一个方法、同一类型，也重复这个过程。Go 1.26.5 的 runtime/reflect.go 里明确写着 methodByName 的实现逻辑就是循环 t.methods 数组。
常见错误现象：高频调用场景（如 JSON 序列化中间件、RPC 参数绑定）中 CPU 火焰图显示 reflect.methodByName 占比突增；go tool pprof 能直接定位到这一层开销。
- 方法名字符串越长，哈希计算成本越高（虽小但累积）
- 类型方法数越多（比如 ORM 模型有 20+ 方法），遍历耗时越明显
- 即使方法存在，只要没命中首项，就必然多走几步比较
用 reflect.Type.Method(i) 预缓存代替 MethodByName
真正高效的做法，是在初始化阶段把方法索引固定下来，后续直接用整数下标取 —— 因为 reflect.Type.Method(i) 返回的是 reflect.Method 结构体，它包含函数指针、签名等元信息，且不依赖运行时字符串匹配。
使用场景：框架启动时注册 handler、ORM 初始化模型元数据、插件系统加载时解析方法表。
立即学习“go语言免费学习笔记（深入）”；
- 必须确保类型稳定：字段/方法顺序不变，否则缓存的
i值会错位 -
reflect.Method.Func是未绑定接收者的reflect.Value，需配合实例的reflect.Value才能调用（不能直接Call） - 推荐组合写法：
v.Method(i).Call(args)，其中v是目标实例的reflect.Value
MethodByName 返回零值的两个隐蔽原因
很多人以为 “方法名写对了就没问题”，但实际中 MethodByName 返回无效值（.IsValid() == false）往往不是拼写错误，而是更底层的语义断裂。
常见错误现象：panic: call of reflect.Value.Call on zero Value，但打印方法名确认无误；或测试通过、上线后偶发 panic。
- 方法未导出：小写字母开头（如
save()），编译器根本没把它写进类型元信息，reflect.Type.NumMethod()都不计数 - 接收器类型不匹配：定义是
func (s *User) Save()，却传了reflect.ValueOf(User{})（值拷贝），此时MethodByName返回零值而非报错 - 嵌入接口字段为 nil：结构体嵌了
A接口字段，MethodByName能查到Foo（因透出到方法集），但底层A是 nil，调用时仍 panic
字段偏移直访比 MethodByName 快一个数量级
如果你真正想优化的不是“调方法”，而是“取字段值”（比如 ORM 映射、JSON 解析），那 MethodByName 根本不是对手——直接用 reflect.StructField.Offset 做指针运算，速度接近原生访问。
性能影响：实测在 10 万次循环中，FieldByName("Name") 耗时约 8.2ms，而偏移直访仅 0.7ms；且后者无 GC 压力，不触发 race detector 报警（前提是加 //go:build !race）。
- 必须保证结构体字段顺序不变更（加字段只能追加，不能插在中间）
- 字段需是 exported（首字母大写），否则
reflect.TypeOf(t).FieldByName查不到 -
unsafe.Pointer转换需严格配对：先uintptr(unsafe.Pointer(&u)) + offset，再转回目标类型指针
sync.Once 就万事大吉。一旦结构体字段重排、方法增删、或跨包重构，所有基于 offset 或 method index 的缓存都会静默失效——它不报错，只返回错值。 
