最常见原因是接收者类型不匹配：方法定义在*Client上时，必须用reflect.ValueOf(&client)，而非reflect.ValueOf(client)；且方法名须首字母大写导出，否则MethodByName返回无效值。
为什么 reflect.Value.MethodByName 总是返回无效值
最常见原因是接收者类型不匹配。Go 反射严格区分值接收者和指针接收者：如果方法定义在 *Client 上（如 func (c *Client) Method1(d *Method1)），你必须用 reflect.ValueOf(&client)，而不是 reflect.ValueOf(client)。后者拿到的是 Client 类型的 reflect.Value，它没有该方法的方法集。
容易踩的坑：
- 直接对结构体字面量取反射值：
reflect.ValueOf(Client{id: "x"})→ 不可寻址，方法表为空 - 误传值类型变量：
client := Client{...}; reflect.ValueOf(client)→ 即使变量可寻址，MethodByName仍查不到指针接收者方法 - 忽略导出规则：方法名首字母小写（如
method1）永远无法被MethodByName找到，这是语言硬限制，不是权限问题
如何正确构造参数传给 reflect.Value.Call
Call 接收的是 []reflect.Value，不是原始 Go 值。每个参数都必须显式用 reflect.ValueOf() 封装，且类型、指针性必须与方法签名完全一致。
例如目标方法是 func (c *Client) Update(name *string, age int)：
- 第一个参数必须是
*string类型的reflect.Value，即reflect.ValueOf(&name)（注意双层指针语义） - 第二个参数是
int类型的reflect.Value，即reflect.ValueOf(age) - 若传
reflect.ValueOf(name)（name是string），会 panic：类型不匹配 - 若传
nil且方法不接受nil，也会 panic，需提前校验
调用后怎么安全处理返回值
Call 返回 []reflect.Value，长度等于方法声明的返回值个数。不能假设它非空，也不能直接调用 .Interface() 而不检查有效性。
典型场景是带 error 的方法（如 func (c *Client) Do() (int, error)）：
- 先确认
len(results) == 2 - 第一个返回值用
results[0].Int()或results[0].Interface().(int) - 第二个用
if !results[1].IsNil() { err := results[1].Interface().(error) }——IsNil()必须调用，否则对 nilerror调用Interface()会 panic - 即使方法无返回值，
Call也返回空切片，不要索引results[0]
性能差在哪？哪些地方能缓存
MethodByName 每次都做字符串哈希 + 线性遍历方法表，比直接调用慢 50–100 倍，且无法内联。但很多场景下只需启动时解析一次。
可缓存的关键项：
-
reflect.ValueOf(receiver).MethodByName(name)的结果 —— 这是一个可调用的reflect.Value，只要 receiver 类型不变就能复用 -
reflect.TypeOf(arg).Kind()等类型元信息，避免循环中重复调用reflect.TypeOf() - 字段索引（如
reflect.TypeOf(T{}).FieldByName("ID").Index），比每次FieldByName查找快得多
真正难处理的是参数类型的动态适配 —— 如果参数来自 JSON 或配置，类型不确定，就绕不开运行时 reflect.ValueOf()，这时只能接受开销，别在高频路径用。
