methodbyname 返回 nil 的根本原因是方法不可导出或接收者类型不匹配：必须首字母大写且接收者类型与传入对象一致；调用前须用 isvalid() 判空，参数需严格匹配类型，panic 会作为最后一个返回值出现。
MethodByName 返回 nil 的常见原因
调用 reflect.ValueOf(obj).MethodByName("Foo") 返回 nil，不是因为方法名拼错（那会 panic），而是因为该方法不可被反射调用——即它不是导出方法（首字母小写）。Go 反射只允许访问导出字段和导出方法，这是强制的可见性限制。
例如：func (t *T) privateMethod() {} 永远无法通过 MethodByName 获取；而 func (t *T) PublicMethod() {} 才行。
- 检查方法名是否首字母大写（必须）
- 确认接收者是值类型还是指针类型：若方法定义在
*T上，但你传入的是T值，则MethodByName仍返回nil（值类型无法调用指针接收者方法） - 用
reflect.ValueOf(obj).NumMethod()打印实际可用方法数，快速验证是否“看见”了目标方法
调用前必须确保 Value 是可调用的
reflect.Value.MethodByName("Name").Call(...) 会 panic：“call of reflect.Value.Call on zero Value”，根本原因是调用链中间某一步返回了零值 reflect.Value。最常见路径是：MethodByName 返回 nil，但没检查就直接调用 Call。
正确做法永远加判空：
v := reflect.ValueOf(obj)
method := v.MethodByName("DoSomething")
if !method.IsValid() {
log.Fatal("method DoSomething not found or not exported")
}
result := method.Call([]reflect.Value{...})
-
IsValid()是唯一安全判断方式，不能用== nil或!= nil——reflect.Value是结构体，不支持直接比较 - 即使方法存在，若
v是不可寻址的（比如传入普通 struct 值而非指针），且方法接收者是*T，MethodByName仍返回无效值 - 如果原对象是
T类型，但方法定义在*T上，应传&obj而非obj
参数传递必须用 []reflect.Value，且类型严格匹配
Call 接收一个 []reflect.Value，每个元素对应方法的一个参数。这里最容易出错的是类型擦除后未还原——比如你有一个 string 变量 s，不能直接写 reflect.ValueOf(s) 就完事，必须确保其 Kind 和方法签名中声明的参数类型一致（例如方法要 io.Reader，你就得传 reflect.ValueOf((*bytes.Buffer)(nil)).Elem() 这类能转成接口的值）。
- 基本类型（
int,string等）用reflect.ValueOf(x)即可 - 接口类型参数，必须传一个实现了该接口的具体值，且
reflect.ValueOf包裹的是该具体值（不是接口变量本身） - 结构体字段或嵌套字段需用
.FieldByName或.Index显式取值，不能靠自动解包 - 返回值是
[]reflect.Value，哪怕方法无返回值，也会返回长度为 0 的切片；若有多个返回值，按顺序排列
panic 捕获与错误传播的实际处理
反射调用中，方法内部 panic 不会向上冒泡到外层函数，而是被包装成 reflect.Value 的返回值之一，其 Kind() 为 reflect.Interface，且底层是 runtime.Error。不显式检查，就会静默吞掉 panic。
标准做法是检查最后一个返回值（Go 方法 panic 时，recover 后的 error 总是最后一个返回值）：
results := method.Call(args)
if len(results) > 0 {
if errV := results[len(results)-1]; errV.Kind() == reflect.Interface && errV.IsNil() == false {
if err, ok := errV.Interface().(error); ok {
// 处理 error
}
}
}
- 不要依赖
recover()包裹整个Call——它捕不到反射内部的 panic - 若方法签名不含 error 返回值，但内部 panic 了，
Call仍会返回[]reflect.Value，其中最后一个就是 panic 的 error 值（Go 运行时自动注入） - 真正需要 recover 的场景，是在反射调用前用
defer/recover包一层函数，但这属于业务逻辑控制，不是反射 API 本身责任
reflect.ValueOf，而是搞清原始对象的类型形态、方法接收者类型、参数运行时类型这三者的对齐关系。稍有不匹配，MethodByName 就沉默失效，或者 Call 直接 panic。
