Method(i) 的索引是方法声明顺序的0-based偏移而非字段序号，顺序不保证与源码一致或字母排序；硬编码索引易因方法增删导致错位调用甚至panic，应始终循环遍历查找。
Method(i) 的索引不是字段序号，而是方法声明顺序的偏移
很多人看到 Method(i) 就下意识类比 Field(i)，以为 i 是“第几个字段”或“按定义位置编号”，其实完全不是。它只是按 NumMethod() 返回的方法总数做 0-based 索引，且顺序不保证与源码一致，也不按字母排序——Go 反射不承诺任何稳定顺序。
常见错误是硬编码 m := typ.Method(2) 去取某个特定方法，一旦类型新增/删减方法，索引就错位，运行时可能调到完全无关的方法，甚至 panic。
- 永远用循环遍历：
for i := 0; i - 需要定位具体方法时，用
MethodByName("Foo")，而不是靠索引猜 - 若必须依赖序号（如测试断言），应配合方法名校验：
if m.Name == "Bar" { ... }
指针接收者 vs 值接收者：NumMethod() 结果完全不同
NumMethod() 返回的数量取决于你传给 reflect.TypeOf() 的类型是值类型还是指针类型。同一个结构体，reflect.TypeOf(MyStruct{}) 和 reflect.TypeOf(&MyStruct{}) 的 NumMethod() 可能差一倍——因为指针类型的方法集包含所有值接收者 + 指针接收者方法，而值类型只含值接收者方法。
典型坑：写了个方法 func (s *MyStruct) Save()，却用 reflect.TypeOf(MyStruct{}).NumMethod() 查，结果为 0，误判“没方法”。
立即学习“go语言免费学习笔记（深入）”；
- 要获取完整方法集，统一用指针类型：
reflect.TypeOf(&MyStruct{}).Elem()得到结构体类型，再调NumMethod() - 若原始变量是值类型，别直接
reflect.TypeOf(x)，先转指针：reflect.TypeOf(&x).Elem() - 注意：即使方法签名相同，
func (s MyStruct) Foo()和func (s *MyStruct) Foo()在反射中是两个独立方法
Method(i).Func.Call() 必须显式传入接收者，不能直接调
reflect.Method.Func 是一个未绑定接收者的函数值，不是可直接执行的闭包。直接 m.Func.Call(args) 会 panic：call of reflect.Value.Call on zero Value，因为缺少第一个参数——接收者本身。
正确调用链是：拿到实例的 reflect.Value → 构造参数切片 → 把接收者 prepended 进去 → 再 Call。
- 值接收者：用
reflect.ValueOf(instance) - 指针接收者：用
reflect.ValueOf(&instance)或已有的指针变量reflect.ValueOf(ptr) - 参数构造必须是
[]reflect.Value，且第一个元素是接收者：allArgs := append([]reflect.Value{receiver}, args...) - 漏掉
receiver或类型不匹配（比如该传指针却传了值），都会在 Call 时 panic
MethodByName 查不到方法？先看首字母和接收者类型
MethodByName("DoSomething") 返回零值，90% 的原因是方法未导出或接收者不匹配。Go 反射严格遵循导出规则：方法名必须首字母大写，且 reflect.Value 的底层值必须能支撑该方法的接收者类型。
例如方法定义为 func (s *DB) Query()，但你传的是 reflect.ValueOf(DB{})（值类型），MethodByName 就会返回无效值——即使名字对、首字母大写，也查不到。
- 检查方法名：
"Do"✅，"do"❌ - 检查接收者：指针方法 → 传
&obj；值方法 →obj或&obj都行 - 永远在 Call 前加防护：
if !method.IsValid() || !method.CanCall() { return errors.New("method not available") } - 不要对
interface{}直接反射，先断言非 nil，再判断具体类型
最易被忽略的是：Method(i) 和 MethodByName 的行为差异远不止“枚举 vs 查找”——前者绕过导出检查（只要在方法集里就返回），后者只返回导出方法；而 Func.Call 的接收者绑定逻辑，又和 Value 的可寻址性深度耦合。这些点不串起来看，单点修复反而容易引入新问题。
