reflect.Value.Call需传[]reflect.Value，参数须用reflect.ValueOf转换且类型数量严格匹配；指针接收者方法必须传指针反射值；...interface{}函数需手动展开切片；性能差且类型不安全，应谨慎使用。

如何用 reflect.Value.Call 传参调用函数

Go 的 reflect.Value.Call 是动态调用函数的核心，但它不接受普通参数，只接受 []reflect.Value。直接传 int、string 会 panic：「reflect: Call using zero Value argument」。

• 必须把每个实参转成 reflect.Value，常用 reflect.ValueOf(x)
• 参数顺序、类型、数量必须和目标函数签名严格一致，否则 panic 或静默失败
• 如果函数有指针接收者（如 (*MyStruct).Method），必须传入指针的 reflect.Value，不能传值
• 返回值也是 []reflect.Value，需手动取 [0].Interface() 转回原类型

func add(a, b int) int { return a + b }
v := reflect.ValueOf(add)
result := v.Call([]reflect.Value{reflect.ValueOf(3), reflect.ValueOf(4)})
fmt.Println(result[0].Int()) // 输出 7

调用带指针接收者的方法时容易 panic 的原因

用 reflect.Value.MethodByName 获取方法后调用失败，常见原因是：目标结构体是值而非指针，但方法定义在 *T 上。

• reflect.ValueOf(s) 得到的是值副本，其 MethodByName 对 *T 方法返回无效值（IsValid() == false）
• 正确做法是传指针：reflect.ValueOf(&s)，再调用 MethodByName
• 即使方法本身不修改字段，只要签名是 func (*T) Foo()，就必须用指针反射值调用

type Counter struct{ n int }
func (c *Counter) Inc() { c.n++ }
s := Counter{}
// ❌ 错误：v 是 Counter 值，没有 *Counter 的方法
v := reflect.ValueOf(s).MethodByName("Inc")
if v.IsValid() { v.Call(nil) } // 不会执行

// ✅ 正确：传 &s，v 才有效
v = reflect.ValueOf(&s).MethodByName("Inc")
v.Call(nil)

如何安全地处理可变参数（...interface{}）函数

反射调用形如 func(...interface{}) 的函数时，不能直接把切片当可变参数展开，否则会被当作单个 []interface{} 参数传入。

• 必须将切片元素逐个转为 reflect.Value，再构造成 []reflect.Value
• 若原始参数是 []interface{}，需先用 reflect.ValueOf(slice).Slice(i, j) 拆解，或用循环 reflect.ValueOf(slice[i])
• 注意：...interface{} 函数内部仍看到多个独立参数，不是一整个切片

func printAll(vals ...interface{}) {
    for _, v := range vals { fmt.Print(v, " ") }
}
v := reflect.ValueOf(printAll)
args := []interface{}{"hello", 42, true}
vals := make([]reflect.Value, len(args))
for i, a := range args {
    vals[i] = reflect.ValueOf(a)
}
v.Call(vals) // 输出：hello 42 true

性能与类型擦除带来的隐性成本

反射调用比直接调用慢 10–100 倍，且绕过编译期类型检查，错误会在运行时暴露。

• 每次 reflect.ValueOf 都触发接口转换和类型信息查找，高频场景应缓存 reflect.Value 或改用代码生成（如 go:generate）
• 无法内联、无法逃逸分析优化，参数和返回值都经历两次装箱/拆箱（interface{} → reflect.Value → 实际类型）
• 如果只是需要「按字符串名调用已知函数」，建议用 map[string]func() 预注册，而非反射

真正需要反射的场景其实很窄：通用序列化、RPC 方法分发、测试桩注入——别为了“看起来灵活”而滥用 reflect.Call。