reflect.Value.Call 比直接调用慢得多，因其需动态执行方法查找、参数封包、类型检查与返回值解包，无内联和编译期优化；应缓存 reflect.Value、避免 MethodByName、优先用代码生成或泛型替代。
reflect.Value.Call 为什么比直接调用慢得多
因为 reflect.Value.Call 不是跳转到函数地址执行，而是走了一整套运行时方法查找 + 参数封包 + 类型检查 + 返回值解包流程。每次调用都要重新解析函数签名、校验参数个数和类型、构造 reflect.Value 列表，最后才真正 invoke——这中间没有内联、没有编译期优化，全是动态 dispatch。
缓存 reflect.Value 而不是反复调用 reflect.ValueOf
直接传函数变量给 reflect.ValueOf 是安全的，但千万别传指针再取 Elem()，否则得到的是函数指针的反射值，Call 会 panic。正确做法是：
- 只对具体函数字面量（如
handleUserRequest）调用reflect.ValueOf，一次初始化，全局复用 - 不要在热路径里写
reflect.ValueOf(fn).Call(...)，避免重复分配reflect.Value实例（约 96 字节/次） - 确认
fn是非接口的具名函数或闭包，不能是interface{}或函数类型接口
用 reflect.Method 替代 MethodByName 做函数寻址
reflect.Value.MethodByName("Save") 每次都线性遍历方法表做字符串匹配，字段越多越慢；而 reflect.Value.Type().Method(i) 返回的是只读结构体常量，可安全缓存。实际操作建议：
- 启动时按类型预建方法索引表，比如
map[reflect.Type]map[string]int - 用
reflect.Value.Method(i)获取可调用的reflect.Value，再缓存这个值 - 避免在循环中调用
MethodByName，哪怕类型完全相同，开销也不会复用
真正快的替代方案：代码生成或泛型约束
反射函数寻址的损耗本质是“把编译期确定的事拖到运行时做”。2026 年主流工程实践已转向更可控的方式：
立即学习“go语言免费学习笔记（深入）”；
- 用
go:generate配合ast解析，为每个 handler 生成专用调用桩（stub），调用开销趋近于零 - 对固定参数模式（如
func(ctx context.Context, req *T) error），用泛型封装，避免任何反射 - 如果必须动态，优先用类型断言（
v, ok := i.(interface{ Handle() })）而非反射，失败成本远低于MethodByName查找
最易被忽略的一点：缓存 reflect.Value 只解决“调用入口”问题，但若函数体内还大量用 FieldByName 或 Set，整体性能仍卡在字段访问上——函数寻址只是冰山一角。
