必须确保反射调用指针接收者方法时传入可寻址的指针类型，因值类型方法集不含指针接收者方法，methodbyname 会返回零值导致 call panic；值接收者方法虽可调用但无法修改原值，易致逻辑错误。
reflect.Value.Call 传值时 panic: call of reflect.Value.Call on zero Value
这个错误常被误认为是反射写法问题，其实根源在接收者类型不匹配。当你用 reflect.ValueOf(obj).MethodByName("Foo").Call(args) 调用一个指针接收者方法时，如果 obj 是值类型（如 MyStruct{}），reflect.ValueOf(obj) 返回的是不可寻址的 Value，其 MethodByName 查不到该方法——因为指针接收者方法不在值类型的方法集中。
- 值类型
MyStruct{}的方法集只含值接收者方法；指针接收者方法（如func (m *MyStruct) Save()）根本不在里面 -
MethodByName找不到方法，返回零值reflect.Value，后续.Call()必然 panic - 即使你手动调用
reflect.ValueOf(&obj).MethodByName("Save")，也得确保obj是变量（可寻址），不能是字面量（如MyStruct{}直接传入）
如何安全地用反射调用指针接收者方法
核心原则：反射调用前，必须让目标对象是可寻址的指针类型。不是“能不能”，而是“必须是”。
- ✅ 正确：先声明变量，再取地址：
var m MyStruct; v := reflect.ValueOf(&m) - ✅ 正确：直接构造指针字面量：
v := reflect.ValueOf(&MyStruct{Name: "x"}) - ❌ 错误：
v := reflect.ValueOf(MyStruct{Name: "x"})—— 值类型，方法集不含指针接收者方法 - ❌ 错误：
m := MyStruct{}; v := reflect.ValueOf(m).Addr()——m是不可寻址的临时值，.Addr()会 panic
值接收者方法在反射中“看起来更宽容”，但有隐藏陷阱
值接收者方法能被 reflect.ValueOf(value) 和 reflect.ValueOf(&value) 同时调用，容易让人误以为它更通用。但要注意：
- 调用
reflect.ValueOf(value).MethodByName("Get")时，方法内部操作的是 value 的副本，任何字段修改都无效 - 若该方法本意是读写混合（比如缓存填充、状态标记），用值接收者反射调用后，原始结构体状态未变，业务逻辑可能静默失效
- 反射无法绕过 Go 的方法集规则：值接收者方法永远无法修改原值，无论你怎么传参或包装
接口断言 + 反射组合场景下的典型失败
当你要对 interface{} 做反射调用，又依赖接口实现时，接收者类型错配会导致双重失败：
- 假设接口
Saver要求func (s *MyStruct) Save()，而你传入MyStruct{}给interface{} - 此时
interface{}底层是MyStruct类型，不满足Saver接口，类型断言val.(Saver)先失败 - 即使跳过断言、强行
reflect.ValueOf(val).MethodByName("Save")，仍因方法不在值类型方法集中而返回零值 - 修复路径唯一：上游必须传
&MyStruct{}，且确保它是变量或可寻址字面量
reflect.ValueOf(x) 的行为完全取决于 x 的静态类型和可寻址性，而不是你“想让它做什么”**。值接收者方法能被反射调用，不等于它适合被反射调用；指针接收者方法调用失败，也不是反射的 bug，而是你在用值类型去碰一个只属于指针契约的门。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
