Value.Call只能调用已绑定接收者的方法值，Method.Func.Call需显式传接收者且性能略低；高频场景应缓存反射值或避免反射。
Value.Call 调用的是方法值，不是方法集
Go 的反射中 Value.Call 只能调用「已绑定接收者」的方法值（method value），不能直接调用未绑定的「方法表达式」（method expression）。如果你传入的是 reflect.ValueOf(&obj).MethodByName("Foo")，它返回的是一个绑定了 &obj 的 Value，此时 .Call() 是安全的；但若误用 reflect.ValueOf(obj).MethodByName("Foo")（值接收者方法对指针调用），会 panic：reflect: Call of unaddressable value。
- 值类型变量必须取地址才能调用指针接收者方法，否则
Value.Call失败 - 接口变量直接调用
MethodByName后Call是 OK 的，因为接口底层已持地址 - 常见错误：把
reflect.ValueOf(someStruct)当成可调用对象，实际需reflect.ValueOf(&someStruct)
Method.Func 返回的是未绑定的方法表达式
Method.Func 是 reflect.Method 结构体的字段，它返回一个 reflect.Value，代表该方法的函数形式（即 method expression），形如 (*T).Foo。它不绑定任何实例，调用时必须显式传入接收者作为第一个参数。
- 调用方式是
method.Func.Call([]reflect.Value{reflect.ValueOf(&obj), ...})，第一个参数必须是合法接收者 - 值接收者方法可用
reflect.ValueOf(obj)传入；指针接收者必须传reflect.ValueOf(&obj) - 相比
Value.Call，Method.Func.Call多一次参数拼接，性能略低，但灵活性更高（比如动态构造接收者）
性能差异主要来自调用路径和类型检查开销
两者底层都走 callReflect，但 Value.Call 少一次参数预处理 —— 因为接收者已固化在 Value 内部。而 Method.Func.Call 每次都要校验传入的第一个参数是否匹配接收者类型，且参数切片需额外分配。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 简单场景下，
Value.Call比Method.Func.Call快 10%–20%，差别不大，但高频反射调用（如 ORM 字段 setter）可测出差距 - Go 1.21+ 对
Value.Call做了部分内联优化，但Method.Func仍绕不过反射参数解析 - 真正拖慢性能的从来不是选哪个 API，而是反复
MethodByName查找 —— 应缓存reflect.Method或reflect.Value
别在热路径上用反射调用方法
无论选 Value.Call 还是 Method.Func.Call，它们本质都是运行时动态分派，无法被编译器内联或优化。一旦出现在循环、HTTP handler、数据库 scan 等高频路径，CPU profile 里立刻显眼。
立即学习“go语言免费学习笔记（深入）”；
- 替代方案优先级：接口断言 > 类型 switch > 生成代码（如 go:generate） > 缓存后的反射 > 直接反射
- 缓存
reflect.Value时注意：它包含指向原值的指针，如果原值被 GC 或重用，缓存可能失效（尤其 map/slice 中的 struct 字段） - 最易忽略的一点：
Value.Call成功不代表业务逻辑正确 —— 它不校验 panic 捕获、error 返回约定、甚至参数个数错位都只在运行时报错
