reflect.Value.Call 慢在运行时重建调用栈：需校验导出性/可寻址性/参数匹配，转换切片为栈帧，触发分支预测失败、逃逸不准和堆分配，开销达80–120 ns，是直接调用的50–100倍。
reflect.Value.Call 本质是运行时重建调用栈，不是“慢在语法糖”，而是每次都要重走完整校验与装包链路——它绕过了编译器所有优化，且无法内联。
为什么 reflect.Value.Call 比直接调用慢 50–100 倍
这不是参数转换慢一点的问题，而是整个调用路径被强制拉到运行时：校验方法是否导出、接收者是否可寻址、参数个数和类型是否严格匹配；再把 []reflect.Value 转成底层栈帧格式；最后跳进 runtime 的 call 汇编入口。每一步都触发 CPU 分支预测失败、逃逸分析不准、GC 堆分配（哪怕只传一个 int，[]reflect.Value 也得新分配）。
压测数据很说明问题：func() {} 直接调用约 1.2 ns，而 reflect.Value.Call 稳定在 80–120 ns；若参数含 interface{} 或嵌套 struct，开销轻松破 200 ns，并同步抬高 GC 压力。
- 校验阶段（导出性、可寻址性、参数数量）占总开销约 15–20%，缓存
MethodByName只能省这部分 -
Call本身无法跳过：每次都要分配临时切片、做类型转换、构造栈帧、保存恢复寄存器 - 返回值是
[]reflect.Value，取rets[0].Interface()又触发一次接口值构造 + 逃逸重判
method.Call panic: “call of reflect.Value.Call on zero Value” 怎么修
这不是参数传错了，是 method 本身无效。最常见原因：方法名小写（如 doSomething），或接收者类型不匹配（定义为 func (s *MyStruct) Foo()，却传了 reflect.ValueOf(MyStruct{})）。
立即学习“go语言免费学习笔记（深入）”；
永远在 Call 前加两道检查：
-
if !method.IsValid()—— 方法不存在或非导出 -
if !method.CanCall()—— 接收者不可寻址（比如传了值类型而非指针） - 如果输入是
interface{}，先断言非nil：if obj == nil，再做reflect.ValueOf(obj)
别依赖文档说“应该能工作”，CanCall() 是唯一可信判断。
缓存什么才真正减少开销
缓存 reflect.Value.MethodByName("Foo") 效果有限——它绑定了具体实例地址，无法复用，还可能阻碍 GC 回收。真正该缓存的是 reflect.Method 或其对应的 reflect.Value（前提是接收者稳定）。
- 推荐方式：
cache[uintptr(unsafe.Pointer(t))][methodName] = method，其中t是reflect.TypeOf(&v).Elem()得到的类型指针 - 不要用
t.String()当 key——匿名 struct 或 vendoring 下会失效 - 别缓存
reflect.ValueOf(instance)，它每次新建、不可比较、不能当 map key - 缓存结构建议带签名：
struct{ method reflect.Value; in, out []reflect.Type }，方便后续预检参数
热路径上彻底绕过 Call：用 MakeFunc 生成闭包
如果每秒调用上千次，光靠缓存治标不治本。关键要把反射挪出热路径：初始化阶段用 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(args) → 实际是普通函数调用
注意：这要求方法签名确定、接收者类型明确，且不适用于动态变化的方法名场景。最容易被忽略的一点是——性能瓶颈不在 Call 动作本身，而在每次调用前的 receiver 校验和参数转换；哪怕你缓存了 reflect.Method，只要还走 reflect.Value.Call，就逃不开这两步。
