MethodByName 慢的核心原因是每次调用需运行时校验导出性、接收者可寻址性及参数格式转换，三步均无法编译优化；压测开销15–25 ns，叠加Call达80–120 ns，高频场景成瓶颈。
MethodByName 为什么慢？不只是查表
它慢的核心原因不是“查找耗时”，而是每次调用都要做三件事：校验方法是否导出、确认接收者可寻址性、把参数 []reflect.Value 转成底层调用栈格式。这三步全是运行时判断，编译器完全无法优化。压测显示，MethodByName 单次调用开销约 15–25 ns，看似不多，但高频场景（如 ORM 字段 setter、RPC 方法路由）下，叠加 Call 的 80–120 ns，整体就成瓶颈。
缓存 Method 比缓存 MethodByName 结果更有效
很多人误以为缓存 method := value.MethodByName("Foo") 就够了，其实这是错的——MethodByName 返回的是一个新构造的 reflect.Value，每次调用都重新打包，逃逸到堆上。真正该缓存的是 reflect.Method 或 reflect.Value 的“方法描述”本身：
- 用
t.MethodByName("Foo")（t是reflect.Type）获取reflect.Method，它不包含值，只含签名和偏移，可安全复用 - 或缓存
v.Method(i)（v是已验证有效的reflect.Value），再在热路径调用.Call() - 避免缓存
v.MethodByName("Foo").Call(...)这种整条链，因为Call每次都分配切片，GC 压力直接拉满
MethodByName 返回零值的两个硬坑
这不是性能问题，是 panic 高发区，且错误信息模糊：
-
MethodByName返回零值，90% 是方法名首字母小写（如doWork），Go 反射严格遵循导出规则，非导出方法不可见 - 剩下 10% 是接收者类型不匹配：定义为
func(s *MyStruct) Foo()，却传了reflect.ValueOf(MyStruct{})（值拷贝），必须用reflect.ValueOf(&obj)或确保原始变量本身就是指针 - 永远在调用前加
if !method.IsValid() || !method.CanCall()，别等Call时才 panic
比缓存更快的替代方案：代码生成 + 类型断言
如果你的调用目标是固定接口（比如所有 handler 都实现 Handler），反射纯属浪费：
- 用
go:generate工具扫描结构体，生成类型安全的 dispatch 函数，调用开销降到 1–2 ns - 对已知类型组合，优先用类型断言：
if h, ok := obj.(Handler); ok { h.ServeHTTP(...) }，零反射、零分配、可内联 -
MethodByName只应在真正动态的场景存在：配置驱动的插件系统、用户自定义脚本注入、通用序列化库字段映射等
缓存能减掉 15–20% 开销，但绕不开反射本身的汇编级成本；真正要快，得让编译器在编译期就把调用路径钉死。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
