MethodByName 返回 nil 是因方法未导出、接收者类型不匹配或传入值为 nil；需确保首字母大写、用正确指针/值类型调用，并先校验 method.IsValid() 再 Call。
MethodByName 返回 nil 怎么办
调用 reflect.Value.MethodByName 后返回零值（IsValid() == false），不是 panic，而是静默失败——这是最常被忽略的起点。
- 方法必须是**导出的**（首字母大写），
reflect看不到小写开头的方法，哪怕你用指针传入也不行 - 调用对象必须是
reflect.Value类型，且底层值不能是 nil；如果原结构体变量是 nil 指针，reflect.ValueOf(ptr).Elem()会 panic，但MethodByName反而返回 nil - 确认你传的是「方法所属的实例」，不是类型本身：用
reflect.ValueOf(&s)而非reflect.ValueOf(s)（除非方法接收者是值类型且你确定要拷贝）
调用带参数的方法时 panic: call of reflect.Value.Call on zero Value
这个错误不是参数写错了，而是 MethodByName 本身返回了零值，后续直接 .Call 就崩。本质还是上一条的问题没解决，但容易误判为参数问题。
- 务必先检查
method.IsValid()，不校验就 Call 是 Golang 反射里最典型的“自信型崩溃” - 参数必须是
[]reflect.Value切片，每个元素都要用reflect.ValueOf(arg)包一层；int、string 这些基础类型可以，但 interface{} 需要小心，它可能被反射当成reflect.Interface类型而非你期望的具体类型 - 如果方法接收者是指针，但你传的是值的
reflect.Value，MethodByName会返回 nil —— 值类型实例无法调用指针接收者方法
为什么 struct 字段能取到，方法却总找不到
字段和方法在反射中的可见性规则不同：字段只要导出就能看到（Type.FieldByName），但方法还额外受「接收者类型」约束。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 假设方法定义为
func (s *MyStruct) Do()，那你必须用*MyStruct的 reflect.Value 去查，用MyStruct的值去查一定失败 -
reflect.Type.NumMethod()和reflect.Type.Method(i)能列出所有导出方法名，建议调试时先打印一遍，确认名字拼写和接收者类型是否匹配 - 注意大小写敏感：
"Do"和"do"在 Go 里是两个世界，反射不会自动驼峰转换
性能差得离谱？别在热路径用 MethodByName
每次 MethodByName 都要字符串哈希 + 线性查找方法表，比直接调用慢 100 倍以上，而且没法内联、逃逸分析也失效。
立即学习“go语言免费学习笔记（深入）”；
- 如果方法名是固定的（比如配置驱动的 handler 名），启动时缓存
reflect.Value结果，运行时只 Call - 避免在 for 循环里反复调用
MethodByName；宁可提前查好，存成 map[string]reflect.Value - 更彻底的替代：用代码生成（
go:generate+reflect扫描一次生成静态 dispatch 函数），或者改用接口断言——只要类型已知，if f, ok := obj.(interface{ Do() }); ok { f.Do() }快得多也安全得多
反射调用方法这件事，表面是动态性，实际是拿可读性和性能换来的妥协；真正需要它的场景极少，多数时候只是没想清楚接口怎么设计。
