用reflect.Value.Call调用方法前必须确保是可导出方法，且obj为指针类型；参数需严格匹配类型并包装为[]reflect.Value；Call返回值恒为[]reflect.Value切片，须校验长度与类型，反射panic不可recover。
用 reflect.Value.Call 调用方法前必须确保是可导出方法
Go 的反射机制无法调用非导出（即小写开头）的方法，哪怕对象本身是可寻址的。这是常见报错 panic: reflect: Call of unexported method 的根本原因。
实操建议：
- 目标方法名必须以大写字母开头，例如
DoSomething，而非doSomething - 传入
reflect.ValueOf(obj).MethodByName("DoSomething")前，obj必须是指针类型（如&MyStruct{}），否则无法获取到指针接收者方法 - 若方法定义在值接收者上（
func (s MyStruct) Method()），则reflect.ValueOf(MyStruct{})也能获取并调用；但混合使用时容易混乱，统一用指针更稳妥
参数必须包装成 []reflect.Value 切片且类型严格匹配
reflect.Value.Call 不接受普通 Go 值，所有参数都得转成 reflect.Value，且顺序、数量、底层类型必须与方法签名完全一致——连 int 和 int64 都不兼容。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 传
int(42)给期望int64的参数 → panic:reflect: Call using int as type int64 - 少传一个参数 → panic:
reflect: Call with too few input arguments - 传了
nil但方法参数是非接口/非指针类型 → panic:reflect: Call of nil func（实际是参数转换失败）
正确做法：
- 用
reflect.ValueOf(arg).Convert(targetType)显式转换类型（需提前通过reflect.TypeOf(method).In(i)获取第 i 个参数类型） - 对结构体字段、切片、map 等复合类型，直接用
reflect.ValueOf(x)即可，无需手动拆解
type Calculator struct{}
func (c *Calculator) Add(a, b int64) int64 { return a + b }
calc := &Calculator{}
method := reflect.ValueOf(calc).MethodByName("Add")
args := []reflect.Value{
reflect.ValueOf(int64(10)),
reflect.ValueOf(int64(20)),
}
result := method.Call(args)[0].Int() // 返回 int64，用 .Int() 取值
处理返回值时注意 Call 总是返回 []reflect.Value
无论方法声明返回 0、1 还是多个值，Call 的结果永远是切片。忽略这点会导致 panic 或取错值。
使用场景：
- 无返回值：检查
len(results) == 0，不要尝试访问results[0] - 单返回值：用
results[0].Interface()转回原类型，或根据类型调用.Int()/.String()/.Interface() - 多返回值（如
(int, error)）：分别取results[0].Int()和results[1].Interface().(error)，注意第二个必须是error类型才能断言
性能影响：每次 .Interface() 都有分配开销，高频调用场景应缓存 reflect.Type 和避免反复反射调用。
动态调用失败时，recover() 捕获不到 panic
反射调用中发生的 panic（比如参数类型不匹配、空指针调用）**不会被外层 defer/recover 捕获**，因为它们发生在 Call 内部的运行时逻辑中，属于“不可恢复的反射错误”。
真正能捕获的只有你代码里主动抛的 panic。所以不能靠 recover 来兜底反射调用失败。
可行方案：
- 调用前用
method.IsValid()检查方法是否存在 - 用
method.Type().NumIn()和method.Type().NumOut()校验参数/返回值数量 - 对每个参数用
arg.Type().AssignableTo(expectedType)预检类型兼容性 - 把反射调用封装进函数，用
reflect.Value.Call后立刻检查len(results) > 0 && !results[0].IsNil()（适用于 error 返回）
最易被忽略的是：即使所有检查都通过，仍可能因接口实现缺失、嵌套指针 nil 等导致运行时 panic——反射的“动态”本质决定了它无法在编译期排除全部风险。
