reflect.Value.MethodByName找不到方法的根本原因有两个：方法未导出（首字母小写）或反射值类型与方法接收者类型不匹配（如方法定义在* T上却传入T）。
为什么 reflect.Value.MethodByName 找不到方法？
常见现象是调用 reflect.Value.MethodByName("Foo") 返回零值，IsValid() 为 false。根本原因只有两个：方法名首字母小写（未导出），或反射对象不是指针类型但方法定义在指针接收者上。
Go 反射只能访问导出（大写开头）的标识符；而方法绑定取决于接收者类型——如果 Foo 定义在 *T 上，你必须传入 reflect.ValueOf(&t)，而非 reflect.ValueOf(t)。
- 检查方法是否导出：确认源码中是
func (t T) Foo()还是func (t *T) Foo() - 验证反射值类型：用
v.Kind() == reflect.Ptr判断是否已取地址 - 必要时自动解引用或取地址：
v = v.Addr()（若v.CanAddr()为true）或v = v.Elem()（若已是指针）
如何安全调用反射获取的方法？
reflect.Value.Call 要求参数是 []reflect.Value，且每个参数必须与方法签名严格匹配（包括可寻址性、类型、数量）。最容易出错的是：传入非指针值去调用指针接收者方法，或参数类型不匹配导致 panic。
建议始终做三步校验：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先用
m.Type().NumIn()检查参数个数 - 用
m.Type().In(i).AssignableTo(arg.Type())校验每个参数类型是否兼容（注意：不能用==直接比类型） - 确保所有参数值都满足可调用条件——例如，若方法接收
*string，则传入的reflect.Value必须是reflect.TypeOf(&s)得到的，且s是可寻址变量
示例片段：
v := reflect.ValueOf(&myObj)
m := v.MethodByName("DoSomething")
if !m.IsValid() {
panic("method not found or not exported")
}
args := []reflect.Value{reflect.ValueOf("hello")}
results := m.Call(args)
反射调用方法时如何处理返回值和错误？
reflect.Value.Call 总是返回 []reflect.Value，即使原函数没有返回值（此时长度为 0），或只返回一个 error（此时需手动提取第 2 个元素）。容易忽略的是：error 类型本身也要用反射判断，不能直接断言为 error。
- 若方法签名是
func() (int, error)，results长度为 2，results[1]是 error 的反射值，需用results[1].Interface()转回 interface{} 后再类型断言 - 若方法 panic，
Call不会传播 panic，而是返回包含reflect.ValueOf(recover())的结果数组（仅当 recover 发生时）——但这不可靠，推荐在调用前用defer/recover包裹整个反射调用块 - 空接口返回值（如
interface{}）要小心：它可能包裹任意类型，.Interface()后仍需二次类型判断
性能敏感场景下要不要用反射调用方法？
反射调用比直接调用慢 10–100 倍，且无法被编译器内联或优化。如果你在循环里反复调用同一方法，应该缓存 reflect.Value 和方法签名，而不是每次重新 MethodByName。
更关键的是：很多所谓“动态”需求其实可用接口替代。例如：
- 想根据字符串名调用不同行为？定义
type Handler interface { Handle() }，用map[string]Handler注册实例 - 需要统一执行前后钩子？用函数值或闭包组合，而非反射
- 仅用于配置驱动的简单路由？考虑 code generation（如
go:generate+stringer）生成静态 dispatch 表
反射真正的适用场景很窄：插件系统、ORM 字段映射、测试 mock 工具、序列化框架底层——这些地方动态性不可绕过，但也要尽量把反射操作移到初始化阶段，运行时只做 Call。
