直接调用比 reflect.Value.Call 快 50–100 倍，因其避免运行时重建调用栈、类型转换和校验开销；高频场景应彻底绕过 Call，而非优化或缓存。
直接调用比 reflect.Value.Call 快 50–100 倍，高频场景下必须绕过它，而不是优化它。
为什么 reflect.Value.Call 一调就慢
它不是转发，而是运行时重建调用栈：校验导出性、接收者可寻址性、参数个数与类型匹配；再把 []reflect.Value 转成底层栈帧格式；最后跳进 runtime 的汇编入口。每一步都绕过编译器优化——内联失效、逃逸分析不准、CPU 分支预测失败。压测显示，空方法 func() {} 的 Call 开销稳定在 80–120 ns，而直接调用仅约 1.2 ns。
常见错误现象：
-
panic: reflect: Call using int as type string—— 参数类型未严格匹配（int和int64视为不同） -
panic: call of reflect.Value.Call on zero Value——MethodByName返回零值（方法未导出 / 接收者非指针 / 指针为 nil） - 循环中每秒调用 10 万次
reflect.TypeOf，GC 分配量翻倍，比缓存后慢 3–5 倍
缓存什么才真正有效
缓存 reflect.Value 本身毫无意义——它每次调用都新建，不可比较、不能当 map key；缓存 reflect.Method 或 reflect.Type 才有用，因为它们是只读、全局单例。
立即学习“go语言免费学习笔记（深入）”；
正确缓存方式：
- 用
uintptr(unsafe.Pointer(t))作 key（t := reflect.TypeOf(&v).Elem()），零开销、不依赖包路径、对匿名 struct 安全 - 避免用
t.String()或t.PkgPath() + "." + t.Name()：前者对匿名 struct 失效，后者在 vendoring 下可能冲突 - 缓存结构建议是
struct{ method reflect.Value; in, out []reflect.Type }，方便后续做参数校验预检
错误方式：map[interface{}]reflect.Method —— 接口底层含值指针，不同变量即使类型相同也无法命中。
热路径上彻底绕过 Call
真正零开销的做法，是在初始化阶段生成纯函数闭包，运行时只做指针传递，无反射参与。
适用场景：签名固定（如所有 handler 都是 func(ctx context.Context) error）、接收者类型明确、方法名不动态变化。
示例：
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(...) → 实际是普通函数调用，无反射开销
更激进的方案（Go 1.14+）：用 unsafe 直接算出方法表偏移，构造函数指针调用。但必须确保签名和参数绝对匹配，否则 runtime crash。
最容易被忽略的性能点
瓶颈不在 Call 动作本身，而在每次调用前的 receiver 可寻址性校验和参数类型逐个转换。哪怕你缓存了 reflect.Method，只要没绕过 Call，就仍要承担这部分开销。高频调用时，真正该做的不是“少调几次”，而是“根本不调”。
