MethodByName返回零值的三个常见原因是：方法名首字母小写导致非导出不可见；接收者类型不匹配（如指针方法却传值类型）；原始值不可寻址（如字面量或临时变量）。
MethodByName 返回零值的三个常见原因
不是拼写错了，而是 Go 反射在运行时根本“看不见”那个方法。最常踩的坑就这三条：
- 方法名首字母小写（如
getData），Go 规定非导出方法在反射中完全不可见，MethodByName直接返回零值 - 接收者类型不匹配：方法定义为
func (s *User) Save()，但你传的是reflect.ValueOf(User{})（值类型），它没有该方法的方法集 - 原始值不可寻址：对字面量或临时变量取反射值，例如
reflect.ValueOf(User{Name: "x"})，得到的Value不可寻址，MethodByName查不到任何指针接收者方法
构造可调用的 reflect.Value 必须满足的条件
关键不在 Call 那一刻，而在 reflect.ValueOf 初始化阶段。必须确保反射值能代表一个真实、可修改、且方法集完整的实例：
- 如果方法接收者是
*T（最常见），一律用reflect.ValueOf(&obj)；若obj已是指针（如obj := &User{}），直接reflect.ValueOf(obj)即可 - 如果方法接收者是
T（值类型），可用reflect.ValueOf(obj)或reflect.ValueOf(&obj).Elem()，但后者更统一，也避免栈上临时值不可寻址的问题 - 调用前加一层保险：
if !v.IsValid() || !v.CanAddr() { panic("invalid or unaddressable") }；对指针类型，还可加v.Elem().IsValid()确保解引用安全
Call 前必须验证的三件事
跳过任意一步，Call 就会 panic，而且错误信息模糊（比如 “call of reflect.Value.Call on zero Value”）：
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 先检查方法值是否有效：
if !method.IsValid() { return errors.New("method not found or unexported") } - 再确认它是函数类型：
if method.Kind() != reflect.Func { return errors.New("not a function") } - 最后验证能否调用：
if !method.CanCall() { return errors.New("cannot call method") }（CanCall()会隐式检查接收者是否可寻址、方法是否导出等）
参数和返回值处理的硬性规则
反射调用不是“传参”，是“构造反射参数切片”，类型、数量、层级必须和签名逐比特对齐：
立即学习“go语言免费学习笔记（深入）”；
- 每个参数必须包装成
reflect.Value，不能直接传原始值；例如字符串要写成reflect.ValueOf("hello")，不能只写"hello" - 参数顺序、个数、底层类型（包括是否是指针）必须与方法签名完全一致；
func (u *User) SetName(name string)要求传入一个string类型的reflect.Value，多一个少一个都 panic - 返回值是
[]reflect.Value切片，需按索引取值并用对应方法提取（如.String()、.Int()、.Interface()），不能直接断言为原类型
CanCall() 这层校验，panic 时只看到“zero Value”却找不到源头。这些约束不是设计缺陷，而是 Go 类型系统在反射层的自然延伸。 
