reflect.Value.Call 比直接调用慢 50–100 倍，因其需运行时重建调用栈：校验导出性/可寻址性/参数匹配、转换参数格式、触发汇编入口，绕过所有编译器优化，且每次调用分配切片引发 GC 压力。
reflect.Value.Call 为什么比直接调用慢 50–100 倍
它不是“简单转发”，而是运行时重建整个调用栈：先校验方法是否导出、接收者是否可寻址、参数个数和类型是否匹配；再把 []reflect.Value 参数转成底层栈帧格式；最后触发 runtime 的 call 汇编入口。每一步都绕过编译器优化——内联失效、逃逸分析不准、CPU 分支预测失败。
压测显示，一个空方法 func() {} 用 reflect.Value.Call 调用，开销稳定在 80–120 ns，而直接调用仅约 1.2 ns。
- 校验阶段占总开销约 15–20%，缓存
MethodByName结果只能省这部分 -
Call本身无法跳过，每次调用都会分配临时参数/结果切片，高频调用会引发 GC 压力飙升 - 即使签名完全确定，
Call仍需做类型转换、栈帧构造、寄存器保存/恢复等汇编级操作
Method.Call panic: “call of reflect.Value.Call on zero Value” 怎么修
这不是参数错，是目标 reflect.Value 本身无效。根源几乎总是没做 IsValid() 检查就直接调 Call。
典型错误链：reflect.ValueOf(nil) → 零值 → MethodByName 返回零值 → Call panic。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 永远在
Call前加两道保险：if !method.IsValid() || !method.CanCall() { return errors.New("method not callable") } - 如果输入是
interface{}，先断言非nil：if obj == nil { return errors.New("nil interface") }，再做reflect.ValueOf -
MethodByName返回零值的常见原因：方法名小写（如doSomething）、接收者类型不匹配（传了MyStruct{}却要调指针接收者方法）
Call 传空切片却 panic: “too few arguments”
这不是编译错误，而是运行时 panic，说明你调用的是一个带参数的方法，却传了 []reflect.Value{} 或 nil。比如 func(r *http.Request) (string, int) 要求一个 *http.Request 参数，但你没传——method.Call(nil) 和 method.Call([]reflect.Value{}) 都等价于“零参数”，直接崩。
- 查方法签名：
method.Type().NumIn()确认需要几个输入参数 - 别依赖
nil：即使无参方法也建议显式传[]reflect.Value{}，避免歧义 - 参数来自 JSON 或配置时，记得先转成
reflect.Value，不是直接塞[]interface{} - 基础类型别名（如
type UserID int）和原生int在反射中视为不同类型，必须严格匹配
指针接收者方法必须用可寻址值调用
你写了 func(t *Task) Do() {}，但用 reflect.ValueOf(Task{}) 去调 MethodByName("Do")，结果 CanCall() 返回 false，Call() panic。因为值类型 Task{} 无法自动取地址，反射拿不到合法 receiver。
- 正确做法：传指针
reflect.ValueOf(&task)，或确保原值可寻址（比如局部变量、字段） -
reflect.ValueOf(task).Addr()只在值本身可寻址时才有效；对字面量或函数返回值调用会 panic - 检查是否可寻址：
v := reflect.ValueOf(&task); v.Elem().CanAddr()比直接v.CanAddr()更稳妥 - 值接收者方法（
func(t Task)）可用值或指针调；指针接收者（func(t *Task)）只能用指针或可寻址值
真正难处理的不是语法，而是运行时约束：导出性、可寻址性、类型精确匹配、零值防御——这些全得靠手动检查，编译器帮不上忙。写一次容易，压测时才发现 Call 是瓶颈，再回头换 MakeFunc 或代码生成，成本就高了。
