reflect.Value.Call 比直接调用慢 50–100 倍，因其需运行时重建调用栈、校验导出性与类型匹配、转换参数格式并触发汇编入口，绕过所有编译器优化；空方法压测显示开销达 80–120 ns，而直接调用仅约 1.2 ns。
reflect.Value.Call 为什么比直接调用慢 50–100 倍
它不是“简单转发”，而是运行时重建整个调用栈：先校验方法是否导出、接收者是否可寻址、参数个数和类型是否匹配；再把 []reflect.Value 参数转成底层栈帧格式；最后触发 runtime 的 call 汇编入口。每一步都绕过编译器优化——内联失效、逃逸分析不准、CPU 分支预测失败。压测显示，一个空方法 func() {} 用 reflect.Value.Call 调用，开销稳定在 80–120 ns，而直接调用仅约 1.2 ns。
缓存 MethodByName 结果不能省掉 Call 开销
很多人以为缓存 reflect.Value.MethodByName("Foo") 就能提速，其实只是省掉了字符串查找和方法表遍历（这部分占总开销约 15–20%），Call 本身仍是重头戏。真正该缓存的是 reflect.Method 对应的 reflect.Value，且必须在类型首次使用时完成：
- 用
uintptr(unsafe.Pointer(t))作 key 缓存，避免t.String()在匿名 struct 或 vendoring 下失效 - 不要缓存
reflect.Value本身——它每次调用都新建，不可比较、无法当 map key - 缓存结构建议是
struct{ method reflect.Value; in, out []reflect.Type }，方便后续做参数校验预检
热路径上彻底绕过 Call：用 MakeFunc 生成闭包
对固定签名的方法（比如所有 handler 都是 func(ctx context.Context) error），reflect.MakeFunc 可在初始化阶段生成纯函数闭包，运行时零反射开销：
typ := reflect.TypeOf((*MyStruct)(nil)).Method(0).Type // 获取方法类型
fn := reflect.MakeFunc(typ, func(args []reflect.Value) []reflect.Value {
recv := args[0].Interface() // 解包接收者
ctx := args[1].Interface().(context.Context)
// 直接调用原方法，不走反射
return []reflect.Value{reflect.ValueOf(recv.(*MyStruct).Foo(ctx))}
})
// 后续直接 fn.Call(...) → 实际是普通函数调用
注意：这种方法要求签名确定、接收者类型明确，且不能用于动态变化的方法名场景。
立即学习“go语言免费学习笔记（深入）”；
别在循环里调用 Call，更别嵌套 Call
常见错误是在 HTTP 中间件中对每个请求都做 v.MethodByName("Validate").Call(nil)，或 ORM 层对每条记录调用 row.Scan 里的反射逻辑。后果不只是慢，还会引发 GC 压力飙升——因为每次 Call 都会分配临时参数切片和结果切片。
- 提前在外层缓存好方法
Value，循环内只调用.Call() - 避免在
Call回调里再触发新反射（比如方法内部又调reflect.ValueOf）——火焰图里会出现多层reflect.Value.Call堆叠 - 字段级绑定（如 JSON 解析）优先用代码生成（
easyjson、ffjson）替代运行时反射
最易被忽略的一点：即使你缓存了所有类型和方法，只要还在热路径上调用 Call，就仍卡在反射的最重一环。真正的性能拐点不在“查得到”，而在“能不能不查”。
