判断方法是否存在，首先需要明确检测入口是reflect.Type还是reflect.Value。前者返回Method和bool，后者返回Value，两种方式在指针接收者场景下会给出不同结果。很多框架在处理动态路由时会忽略这个差异，导致值类型上明明存在的方法检测不到，或者指针接收者方法被错误跳过。下面从反射包的基础能力开始，逐步推演出一个可以用于动态分发的完整方案。
一、从 Type 和 Value 两个入口判断方法是否存在
reflect.Type 提供 MethodByName(name string)，它返回两个值：reflect.Method 和 bool。布尔值直接说明方法是否在类型的方法集中存在。需要注意的是，这里的方法集只包含导出方法，也就是方法名首字母大写的方法。如果结构体里定义了一个小写开头的私有方法，反射包不会把它暴露出来，检测结果会是 false。这跟 Go 编译器的方法集规则一致，但很多开发者会误以为反射能穿透可见性。
另一个入口是 reflect.Value 的 MethodByName(name string)，它只返回一个 reflect.Value。判断方法是否存在的方式是调用返回值的 IsValid() 方法。如果返回的 Value 是无效的，就说明方法不存在。这种方式更贴近实际调用场景，因为你后续可以直接对这个 Value 调用 Call，省去了从 Type 往实例上绑定的步骤。
下面这段代码同时演示了值类型和指针类型的检测差异。结构体 User 有两个方法：值接收者的 Greet 和指针接收者的 SetName。用 reflect.TypeOf 分别检查值时，SetName 并不在方法集中。
package main
import (
"fmt"
"reflect"
)
type User struct {
Name string
}
func (u User) Greet() string {
return "hello " + u.Name
}
func (u *User) SetName(name string) {
u.Name = name
}
func main() {
u := User{Name: "di"}
t := reflect.TypeOf(u)
fmt.Println("NumMethod:", t.NumMethod())
m, ok := t.MethodByName("Greet")
fmt.Println("Greet exists:", ok)
if ok {
fmt.Println("Method name:", m.Name)
}
_, ok2 := t.MethodByName("SetName")
fmt.Println("SetName exists on value type:", ok2)
pt := reflect.TypeOf(&u)
_, ok3 := pt.MethodByName("SetName")
fmt.Println("SetName exists on pointer type:", ok3)
}
运行这段代码会看到值类型的 NumMethod 只有 1，SetName 在值类型上返回 false；而指针类型的 NumMethod 变成 2，SetName 返回 true。这个结果说明：反射检测方法存在与否，和你传入的是值还是指针强相关。如果你只拿到一个 interface{} 参数，内部是值类型，但你想调用它的指针接收者方法，就必须先判断 reflect.ValueOf(v).CanAddr()，能取地址时再用 Addr() 转成指针再检测。
还有一个容易忽略的点：如果传入的是接口类型，NumMethod() 只会返回接口定义的方法，而不是底层动态类型的方法。要拿到底层实现类型的方法集合，得先通过 reflect.TypeOf(v).Elem() 或 reflect.ValueOf(v).Elem() 解包。动态方法反查时一旦混用接口和具体类型，很容易出现检测结果不一致的问题。
二、调用前必须做的签名校验与错误处理
检测到方法存在只是第一步。如果你直接构造参数并调用 Call，参数数量或类型不匹配会立刻触发 panic。框架里最不应该出现的就是因为反射调用导致进程崩溃，所以调用前需要先把方法签名读出来，对照参数逐一校验。方法签名可以从 m.Type() 获取，它返回一个 reflect.Type，其中 NumIn() 表示入参数量，In(i) 返回第 i 个参数的类型。
下面的 SafeCall 函数演示了标准的防护逻辑：先检查方法是否有效，再校验参数数量，最后逐个检查参数类型是否可以赋值给目标入参。对于 nil 参数，可以用 reflect.Zero 生成对应类型的零值，避免空指针问题。
func SafeCall(v interface{}, name string, args ...interface{}) ([]reflect.Value, error) {
val := reflect.ValueOf(v)
m := val.MethodByName(name)
if !m.IsValid() {
return nil, fmt.Errorf("method %s not found", name)
}
mt := m.Type()
if mt.NumIn() != len(args) {
return nil, fmt.Errorf("argument count mismatch: got %d want %d", len(args), mt.NumIn())
}
in := make([]reflect.Value, len(args))
for i, arg := range args {
if arg == nil {
in[i] = reflect.Zero(mt.In(i))
continue
}
av := reflect.ValueOf(arg)
if !av.Type().AssignableTo(mt.In(i)) {
return nil, fmt.Errorf("arg %d type mismatch: got %s want %s", i, av.Type(), mt.In(i))
}
in[i] = av
}
return m.Call(in), nil
}
这段代码中的 AssignableTo 判断很关键。如果调用方传入的是 int 类型，而方法参数是 int64，直接赋值会 panic，但通过类型检查可以提前返回错误。需要注意的是，如果方法有可变参数，NumIn() 会把可变部分算作一个切片类型，调用时你需要把剩余参数打包成对应的切片再传入，否则数量校验会不对。反射调用本身并不帮你处理可变参数展开。
从返回值角度看，m.Call(in) 返回的是 []reflect.Value，每个元素对应方法的一个返回值。如果你只关心调用是否成功，可以忽略返回内容；如果方法 panic 了，反射会把它包装成 reflect.Value.Call 的 panic 继续向上抛。生产环境中可以再包一层 recover，把 panic 转成 error，这样即使业务方法内部有数组越界，也不会直接拖垮整个分发器。
三、把反射检测变成动态方法分发表
检测方法是否存在的最终目的大多是为了动态分发：根据字符串方法名，把请求路由到具体实现。这时候可以借助 map 把方法名和 reflect.Value 关联起来，在初始化阶段扫描一次类型的方法集，缓存所有导出方法的 Value。后续每次调用只需要查 map，不需要再执行 MethodByName 遍历。
下面是一个简化的 MethodRouter 实现。它假设传入的 service 是一个结构体或结构体指针，初始化时扫描 NumMethod() 个方法，把方法名作为 key，reflect.Value 作为 value 存入 map。调用时按名字取出方法，做签名校验后执行。
type AddService struct{}
func (s AddService) Sum(a, b int) int { return a + b }
func (s AddService) Mul(a, b int) int { return a * b }
type MethodRouter struct {
routes map[string]reflect.Value
}
func NewMethodRouter(service interface{}) *MethodRouter {
router := &MethodRouter{routes: make(map[string]reflect.Value)}
val := reflect.ValueOf(service)
typ := val.Type()
for i := 0; i < val.NumMethod(); i++ {
name := typ.Method(i).Name
router.routes[name] = val.Method(i)
}
return router
}
func (r *MethodRouter) Invoke(name string, args ...interface{}) ([]reflect.Value, error) {
m, ok := r.routes[name]
if !ok {
return nil, fmt.Errorf("method %s not registered", name)
}
mt := m.Type()
if mt.NumIn() != len(args) {
return nil, fmt.Errorf("argument count mismatch")
}
in := make([]reflect.Value, len(args))
for i, arg := range args {
if arg == nil {
in[i] = reflect.Zero(mt.In(i))
continue
}
av := reflect.ValueOf(arg)
if !av.Type().AssignableTo(mt.In(i)) {
return nil, fmt.Errorf("arg %d type mismatch", i)
}
in[i] = av
}
return m.Call(in), nil
}
这种路由表在命令行子命令分发、RPC 服务端、插件系统中都很常见。比如你有一个 Tool 集合，每个 Tool 暴露 Execute、Validate 等方法，前端传方法名和参数，后端通过反射快速定位并执行。相比手写 switch-case，反射路由能自动适配新增方法，但代价是参数类型检查被推迟到运行时，编译器无法提前发现错误。
如果方法数量会动态变化，可以用 sync.Map 替代普通 map 来支持并发注册和调用。不过反射 Value 本身不是并发安全的，同一时间多个 goroutine 调用同一个方法，如果方法内部没有共享状态，通常没问题；如果方法会修改接收者字段，就需要在服务层加锁，不能依赖反射路由来保证并发安全。
四、指针接收者、嵌入字段与缓存策略
嵌入字段会对方法检测结果产生直接影响。当一个结构体嵌入了另一个类型，被嵌入类型的导出方法会被提升到外层类型的方法集中。也就是说，你在外层类型上用 MethodByName 也能找到内层类型的方法。这个特性在构建组合式服务时很有用，但也容易造成方法名冲突时不知道调到了哪一个。下面的代码演示了嵌入方法在反射中的可见性。
type Base struct{}
func (Base) Run() {}
type Child struct {
Base
}
func main() {
c := Child{}
t := reflect.TypeOf(c)
_, ok := t.MethodByName("Run")
fmt.Println("embedded Run detected:", ok)
ptr := &c
fmt.Println("pointer embedded Run detected:", ptr.MethodByName("Run").IsValid())
}
实际开发中，嵌入字段的方法提升跟方法名是否冲突有关。如果外层定义了自己的 Run 方法，内层的 Run 在直接 MethodByName 时会被隐藏，但通过遍历 NumMethod() 获得的 Method 记录里仍可能保留信息，这取决于编译器的提升规则。反射结果基本等同于编译器眼中那个类型的方法集，所以检测时要先明确你希望在哪个类型视角下工作。
性能方面，MethodByName 每次调用都会做一次线性查找，方法数量多的时候开销不容忽视。推荐的缓存策略是在服务初始化时执行一次扫描，把方法名映射到 reflect.Value 或封装的调用函数中，后续请求直接查表。反射调用本身比直接函数调用慢不少，通常有几十倍到上百倍的差距，因此不要在纳秒级热点路径里使用这种动态路由。对于普通 RPC 或命令行框架，网络或 IO 开销已经远大于反射消耗，缓存后完全够用。
最后总结一条容易踩的坑：反射能检测到的只是导出方法，且和具体传入类型的方法集绑定。动态方法反查要落地，需要把检测、签名校验、缓存路由拆开处理，不能把 MethodByName 的布尔值当成唯一可信依据。把 Value 缓存起来后，参数签名可以用 m.Type() 提前记录，这样既能快速路由，又能在调用前把类型错误挡在业务逻辑之外。