methodbyname 的 ok 值仅表示导出方法是否存在；它只识别首字母大写的导出方法，小写方法返回 false，且受接收者类型（值/指针）、拼写精度影响，安全不 panic，批量检查需遍历 nummethod。
MethodByName 返回的 ok 值只表示导出方法是否存在
Go 的反射机制严格遵循语言可见性规则：MethodByName 只能查到首字母大写的导出方法，小写方法（如 walk）永远返回 ok == false，这不是 bug，是设计使然。
常见错误是把未导出方法名传进去后反复调试，结果发现怎么都查不到——先确认方法签名是否以大写字母开头。
- 接收者类型影响结果：传
reflect.TypeOf(Person{})查的是值接收者方法；传reflect.TypeOf(&Person{})查的是指针接收者方法（二者方法集不同） - 拼写必须完全一致：大小写、下划线、缩写都不能有偏差，
Sayhello≠SayHello -
MethodByName不会 panic，安全，但返回的Method类型值在ok == false时不可用
遍历 NumMethod 配合 Method(i) 是唯一能批量确认的方法
当你需要检查多个方法、或不确定具体名称时，靠循环 t.NumMethod() + t.Method(i) 更可靠。注意：这些方法按名称字典序排序，不是定义顺序，且只包含导出方法。
示例中用 for i := 0; i 遍历，每次调用 <code>t.Method(i) 得到一个 reflect.Method，它含 Name 和 Type 字段，可直接比对。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 不要在循环里反复调用
MethodByName——性能差，且无额外信息 -
NumMethod()返回的是导出方法总数，对未导出方法始终为 0 - 如果结构体嵌了匿名字段，其方法不会被自动合并进当前类型的
NumMethod()结果中
MethodByName 后必须检查 IsValid() 才能安全调用
查到方法只是第一步，真正调用前还得确认 reflect.Value.MethodByName 返回的值是否有效。因为 MethodByName 在 reflect.Value 层返回的是 reflect.Value，它可能无效（比如接收者是 nil 指针、或原值本身不合法）。
- 正确姿势：
method := rv.MethodByName("Foo"); if !method.IsValid() { return } - 仅靠
ok不够：即使MethodByName返回ok == true，若rv是 nil 指针，method仍会是无效值 - 调用前务必用
method.Call([]reflect.Value{...})，参数必须是reflect.Value类型切片，不能是原始 Go 值
最容易被忽略的接收者类型陷阱
同一个方法，在值类型和指针类型上的可见性可能完全不同。例如 func (p *Person) Save() 在 reflect.TypeOf(Person{}) 上查不到，但在 reflect.TypeOf(&Person{}) 上可以。
如果你传入的是结构体变量而非指针，却去查指针接收者方法，结果一定是 ok == false；反之亦然。这跟 Go 方法集定义完全一致，但容易在反射层被忽视。
- 统一用指针传入更稳妥：
reflect.ValueOf(&obj).MethodByName(...)，覆盖两种接收者 - 避免对
nil指针调用MethodByName：此时reflect.ValueOf(nil).MethodByName(...)会返回无效值，IsValid()为 false - 别依赖
reflect.TypeOf(obj).MethodByName(...)来做运行时调用——它返回的是类型信息，不是可执行对象
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
