reflect.Value.Call panic 的根本原因是传入的 reflect.Value 不可寻址或方法未导出：必须用指针（如 &obj）获取带方法集的 Value，且仅能调用首字母大写的导出方法；参数需严格匹配签名并用 reflect.ValueOf 包装。
为什么 reflect.Value.Call 总 panic：method not found？
不是方法名写错了，而是你传进去的 reflect.Value 没有方法表——常见于直接对结构体字面量取值后调用，比如 reflect.ValueOf(MyStruct{})。这个值是不可寻址的，Go 反射系统不允许对不可寻址的值调用方法。
必须用指针：只有 reflect.ValueOf(&MyStruct{}) 才能拿到带方法集的 reflect.Value，否则 MethodByName 返回零值，Call 时 panic。
- ✅ 正确：
reflect.ValueOf(&myObj).MethodByName("DoSomething") - ❌ 错误：
reflect.ValueOf(myObj).MethodByName("DoSomething")（即使 myObj 是结构体变量） - ⚠️ 注意：
reflect.ValueOf(&myObj).Elem()后再调方法也行，但多一层间接，没必要
参数怎么传进 reflect.Value.Call 才不崩？
Call 接收一个 []reflect.Value，每个元素必须和目标方法签名严格匹配：类型、数量、是否为指针。常见崩溃原因是参数类型不兼容，比如把 int 直接塞进去，而方法要的是 *int 或 interface{}。
- 参数必须是
reflect.Value类型，不能是原始 Go 值；用reflect.ValueOf(arg)包一层 - 如果方法接收指针参数（如
func (s *User) Update(name *string)），你得传reflect.ValueOf(&name)，而不是reflect.ValueOf(name) - 空接口
interface{}参数可以接受任意值，但传入时仍需reflect.ValueOf(x)，反射不会自动解包 - 示例：
method.Call([]reflect.Value{reflect.ValueOf("hello")})—— 前提是方法第一个参数是string或interface{}
调用私有方法（首字母小写）为什么总失败？
Go 的反射遵守导出规则：只有导出（大写开头）的方法才能通过 MethodByName 获取到。reflect.Value.Call 对私有方法完全无权访问，这不是权限问题，是编译期就剥离了反射可见性。
立即学习“go语言免费学习笔记（深入）”；
- ❌
func (u User) doWork() {}→MethodByName("doWork")返回无效值，Callpanic - ✅ 改成
DoWork才能被反射识别 - ⚠️ 即使你用
reflect.ValueOf(&u).UnexportedField之类绕过字段限制，方法依然不行——这是语言层面硬限制，没 workaround
性能差到什么程度？什么时候该放弃反射？
一次 reflect.Value.Call 的开销通常是普通函数调用的 50–100 倍，主要耗在类型检查、栈帧构造、参数复制上。如果你在热点路径（比如 HTTP handler 内部、高频循环里）反复调用，延迟会明显抬升。
- 别用在每秒调用上千次的场景；考虑提前生成闭包或用 interface{} + 类型断言替代
- 如果只在初始化或配置加载时调用几次，影响可忽略
- 注意 GC 压力：
reflect.Value持有对象引用，大量临时反射值可能拖慢 GC - 交叉编译或 cgo 环境下，反射行为更难调试，错误信息也更模糊
真正难的不是写对那几行反射代码，而是判断「这里到底该不该用反射」——多数时候，换个接口设计比硬刚 Call 更省事。
