MethodByName返回零值的三个常见原因是：方法名首字母小写导致不可见；接收者类型不匹配（如指针接收者方法传入值类型）；输入为nil interface{}。
MethodByName 返回零值的三个常见原因
这通常不是代码写错了，而是反射在严格执行 Go 的导出规则和方法集语义。最常导致 MethodByName 返回无效值（.IsValid() == false）的原因有三个：
- 方法名首字母小写，比如
doSomething—— 反射根本“看不见”它，直接返回零值 - 接收者类型不匹配：方法定义为
func (s *MyStruct) Foo()，却传了reflect.ValueOf(MyStruct{})（值拷贝），此时即使名字对、首字母大写，也查不到 - 输入是
nil interface{}，比如var obj interface{} = nil，reflect.ValueOf(obj)得到的是零值，后续所有操作都失效
验证方式很简单：if !method.IsValid() { return errors.New("method not found") } 必须放在 Call 之前，不能省。
指针接收者方法必须用可寻址值调用
Go 正常调用时会自动取地址，但反射不会帮你做这层转换。如果你的方法是 func (t *Task) Run()，那么：
- ✅ 正确：
reflect.ValueOf(&task)（task是Task类型变量） - ✅ 也正确：
reflect.ValueOf(taskPtr)（taskPtr已经是*Task类型） - ❌ 错误：
reflect.ValueOf(task)（值类型，无法调用指针接收者方法）
注意：reflect.ValueOf(&task).Elem() 得到的是值类型反射值，它只包含值接收者方法，不能用于调用 *Task 上的方法。
立即学习“go语言免费学习笔记（深入）”；
参数必须逐个包装成 reflect.Value，且类型严格一致
Call 接收的是 []reflect.Value，不是原始参数切片，也不是 []interface{}。任何类型偏差都会 panic，错误信息却不提示具体哪错了。
- 基础类型别名不兼容：
type UserID int和int在反射中是不同类型，不能混用 - 空参数必须显式写成
[]reflect.Value{}，写nil会导致 “too few arguments” - 调用前建议校验：
if len(args) != method.Type().NumIn() { ... }（NumIn()包含接收者，所以用户参数从In(1)开始算） - 每个参数都要单独
reflect.ValueOf(arg)，不能用reflect.ValueOf([]any{...})
为什么 reflect.Value.Call 比直接调用慢 50–100 倍
这不是配置或写法问题，是底层机制决定的：每次 Call 都要重建调用栈——校验导出性、检查可寻址性、转换参数格式、触发 runtime 汇编入口、分配临时切片。这些步骤全部绕过编译器优化。
- 缓存
MethodByName结果只能省掉校验开销（约 15–20%），Call本身无法跳过 - 高频调用（如每秒万次以上）会明显抬高 GC 压力
- 如果签名固定，考虑预生成函数闭包替代反射，或者用代码生成（
go:generate）避免运行时开销
真正需要反射调用的地方不多，比如 RPC 序列化、插件系统、测试 mock；日常业务逻辑里硬套反射，往往是在用性能换灵活性，得想清楚值不值。
