Go反射不能直接通用化方法调用，因reflect.Value.Call要求参数类型、数量、顺序严格匹配目标签名，且方法须导出、接收者须可寻址；应优先用接口抽象（如Processor）或函数签名func(context.Context, interface{}) (interface{}, error)实现通用性。
Go 的反射不能直接“通用化方法调用”——reflect.Value.Call 要求参数类型完全匹配，且无法绕过接口契约。所谓“通用方法”，本质是靠接口抽象 + 反射辅助，而非反射本身越界操作。
为什么 reflect.Value.Call 不能直接当“万能方法调用器”用
它不接受任意参数列表，所有入参必须是 []reflect.Value 类型，且每个元素的类型、数量、顺序必须与目标方法签名严格一致。传错一个 int 当 int64，或漏掉一个 context.Context，运行时 panic 报 reflect: Call using zero Value argument 或 reflect: Call of non-nil function with zero Value。
- 方法必须导出（首字母大写），否则
reflect.Value.MethodByName找不到 - 接收者必须是可寻址的（比如
&obj而非obj），否则无法调用指针方法 - 返回值若含 error，需手动 unpack 并检查，不能自动透传
用 interface{} + 类型断言替代“反射调用”的常见场景
多数所谓“通用方法”需求，其实只需要统一输入/输出协议，比如日志、校验、序列化。这时硬上反射反而增加复杂度和运行时开销。
- 定义
type Processor interface { Process(interface{}) error }，让具体类型实现它 - 避免在调用侧做
reflect.TypeOf(x).Name()分支判断，而是由实现方决定行为 - 若需动态注册，用
map[string]Processor管理，key 是业务标识（如"user_create"），不是类型名
真正需要反射调用时：封装安全的 SafeCall 辅助函数
只在必须延迟绑定、且参数结构已知的前提下使用。例如 RPC 框架解析 JSON 后调用服务方法。
