直接调用异步函数比反射调用快50–100倍，因reflect.Value.Call需重建调用栈、禁内联、逃逸分析失效、每次分配新切片，且参数/返回值转换开销大，高频下GC压力显著上升。
直接调用异步函数比反射调用快 50–100 倍，reflect.Value.Call 不是“加个反射壳”，而是运行时重建整个调用栈，且无法内联、逃逸分析失效、每次调用都分配新切片——高频场景下 GC 压力会明显上升。
为什么 reflect.Value.Call 调用异步函数延迟高
反射调用本身不区分同步或异步，但异步函数常带 context.Context 和多返回值（如 chan error 或 (int, error)），这放大了反射的固有开销：
-
reflect.Value.Call必须把每个参数转成reflect.Value，再逐个校验类型匹配（比如context.Context传的是值还是指针）；错一位就 panic - 返回值是
[]reflect.Value，哪怕函数只返回一个chan int，你也得先判Kind() == reflect.Chan，再Convert类型，最后Interface()强转——每一步都是运行时分支和接口转换 - goroutine 启动类函数（如
go fn(ctx)）被反射调用后立即返回，但内部逻辑还没跑完；你无法靠Call返回值判断任务状态，只能额外加 channel 或 sync.WaitGroup 同步，又增一层延迟 - 压测显示：空方法
func() {}的reflect.Value.Call开销稳定在 80–120 ns，而直接调用仅约 1.2 ns；异步函数因参数/返回值更复杂，实际延迟更容易突破 200 ns
如何避免 reflect.Value.Call 成为性能瓶颈
缓存 MethodByName 结果只能省掉 15–20% 开销，真正要动的是调用本身：
- 对固定签名的方法（如所有 handler 都是
func(ctx context.Context) error），用reflect.MakeFunc在初始化阶段生成闭包，后续调用就是普通函数跳转，零反射开销 - 别缓存
reflect.Value实例（它绑定了具体值，不可复用），只缓存reflect.Type和方法签名元数据，例如struct{ method reflect.Value; in, out []reflect.Type } - 高频路径（如 HTTP 中间件、RPC 分发）直接放弃反射，改用
go:generate为具体类型生成调用桩，避免运行时任何查找与转换 - 若必须用反射，提前校验参数类型：用
method.Type().NumIn()确认入参个数，用in[i].AssignableTo(expectedType)检查可赋值性，失败就提前报错，别等到Call时才 panic
context.WithTimeout 在反射调用中为何常失效
传一个带 deadline 的 ctx 进去，不代表异步任务真能按时退出——反射不感知 context，生效全看目标函数是否实际使用它：
立即学习“go语言免费学习笔记（深入）”；
- 目标函数内部没做
select { case ，或者没把 <code>ctx传给下游 HTTP/gRPC 调用，那这个ctx就只是个摆设 - 即使函数用了
ctx，反射调用后启动的 goroutine 若未监听ctx.Done()，超时后仍会继续运行，造成 goroutine 泄漏 - 测试时要用
runtime.NumGoroutine()辅助验证：短 timeout + 长 mock 延迟后，goroutine 数是否回落，否则说明取消逻辑没生效 - 别依赖
ctx自动同步；若需等待结果，必须显式收 channel 或调sync.WaitGroup.Wait()，反射调用本身不提供等待语义
最易被忽略的一点：reflect.Value.Call 每次都会新建参数和返回值切片，高频调用下这些临时分配会推高 GC 频率——哪怕你把方法缓存了，这个开销也绕不开。真要压 latency，就得让反射“只出现一次”，比如初始化时用 MakeFunc 生成确定签名的闭包，后面全是直调。
