反射调用方法需确保接收者可寻址且方法导出：首字母大写、传指针（如&obj）、调用前检查method.IsValid()和CanCall()，参数逐个reflect.ValueOf包装并匹配签名，高频场景应缓存Method或预编译。
Go 框架里用反射调用方法，不是“能不能”，而是“怎么避免 panic 并保持可控”。核心就一条：reflect.ValueOf 必须传可寻址值，且方法必须导出。
为什么 MethodByName 返回零值？
最常见原因是方法名首字母小写，比如 doSomething —— Go 反射严格遵循导出规则，非导出成员在反射中不可见，MethodByName 直接返回 reflect.Value 零值，后续 Call 必 panic。
另一个隐蔽原因是接收者类型不匹配：定义为 func (s *MyStruct) Foo()，却传了 reflect.ValueOf(MyStruct{})（值拷贝），此时即使方法导出，MethodByName 也返回零值。
- 检查方法是否首字母大写（
Foo✅，foo❌） - 确认结构体实例是通过指针传入：
reflect.ValueOf(&obj)，不是reflect.ValueOf(obj) - 若原始变量已是指针（如
obj := &MyStruct{}），直接reflect.ValueOf(obj)即可，无需再取地址
Call 时 panic: “call of reflect.Value.Call on zero Value” 怎么修？
这不是参数错，是目标 reflect.Value 本身无效。根源几乎总是：没做 IsValid() 检查，就直接调 Call。
立即学习“go语言免费学习笔记（深入）”；
典型错误链：reflect.ValueOf(nil) → 零值 → MethodByName 返回零值 → Call panic。
- 永远在
Call前加两道保险：if !method.IsValid() || !method.CanCall() { return errors.New("method not callable") } - 如果输入是
interface{}，先断言非 nil：if obj == nil { return errors.New("nil interface") }，再做reflect.ValueOf - 不要依赖文档说“应该能工作”，运行时
CanCall()是唯一可信判断
参数怎么传才不 panic “too many or too few arguments”？
Call 接收的是 []reflect.Value，不是原始参数切片。每个参数都必须单独包装，且类型、数量、顺序与方法签名完全一致——包括基础类型别名、指针层级。
例如方法签名为 func (s *DB) Query(sql string, args ...interface{}) ([]map[string]interface{}, error)，那么 args 中的每个 interface{} 元素都要单独 reflect.ValueOf 包装，不能把整个 args 切片当一个参数传。
- 逐个转换：
params := make([]reflect.Value, len(rawArgs)); for i, a := range rawArgs { params[i] = reflect.ValueOf(a) } - 注意指针参数：方法要
*int，你就得传reflect.ValueOf(&x)，不能传reflect.ValueOf(x) - 变参（
...）需展开：把[]interface{}中每个元素转成reflect.Value后，再拼进参数切片
框架里要不要 recover 拦截反射 panic？
要，但别只靠它兜底。生产级框架必须在调用前做静态校验：方法是否存在、接收者是否可寻址、参数类型是否匹配。recovery 只用于捕获漏网的运行时异常（比如用户自定义插件里写了非法反射逻辑）。
真正容易被忽略的是性能代价：每次 MethodByName 都是字符串哈希查找，Call 涉及大量类型擦除与重装。高频路径（如 HTTP 路由分发）应缓存 reflect.Method 或提前编译为闭包（用 reflect.MakeFunc）。
还有个硬伤：IDE 和静态分析工具对反射调用完全失焦，方法名写错、参数少一个，只能到运行时报 panic —— 所以框架层最好配套提供校验工具或生成代码，而不是裸用反射。
