可用 reflect.Value.Call 调用可导出函数，需传入 []reflect.Value 包装参数，返回值同为 []reflect.Value；CallMethod 则需结构体指针的 reflect.Value 并匹配方法名与签名。
如何用 reflect.Value.Call 调用函数（非方法）
直接调用函数，前提是该函数是可导出的（首字母大写），且你已有其 reflect.Value。注意：reflect.ValueOf(fn) 必须返回一个函数类型的值，否则 Call 会 panic。
常见错误：传入未取地址的闭包、匿名函数或未导出函数 —— 它们无法被 reflect.Value.Call 正常处理。
- 函数必须是可导出的（即使在同一个包内，也建议显式导出）
- 参数需包装成
[]reflect.Value，每个元素用reflect.ValueOf(arg)构造 - 返回值是
[]reflect.Value，需手动解包；若函数无返回值，结果切片为空 - 如果函数有 panic，
Call不会捕获，而是直接向上传播
func Add(a, b int) int {
return a + b
}
func main() {
fn := reflect.ValueOf(Add)
result := fn.Call([]reflect.Value{
reflect.ValueOf(3),
reflect.ValueOf(4),
})
fmt.Println(result[0].Int()) // 输出 7
}
如何用 reflect.Value.CallMethod 调用结构体方法
调用方法前，必须确保你拿到的是结构体实例的指针（*T）的 reflect.Value，否则 CallMethod 找不到指针接收者方法，或对值接收者方法调用失败（尤其当方法修改字段时）。
常见错误：用 reflect.ValueOf(structInstance)（值拷贝）去调用指针接收者方法 —— CallMethod 返回空 reflect.Value，且不报错，容易误判为“方法不存在”。
立即学习“go语言免费学习笔记（深入）”；
- 用
reflect.ValueOf(&s)获取指针的reflect.Value，再调用CallMethod - 方法名必须完全匹配（大小写敏感），且为可导出方法
-
CallMethod第二个参数是方法索引（不是字符串名），需先用MethodByName或遍历NumMethod查找 - 若方法有返回值，需检查
len(results) > 0再取值，避免 panic
type Calculator struct{ Val int }
func (c *Calculator) Inc(by int) int {
c.Val += by
return c.Val
}
func main() {
s := Calculator{Val: 10}
v := reflect.ValueOf(&s) // 注意：取地址
method := v.MethodByName("Inc")
if method.IsValid() {
result := method.Call([]reflect.Value{reflect.ValueOf(5)})
fmt.Println(result[0].Int()) // 15
fmt.Println(s.Val) // 15，已修改
}
}
reflect.Value.Call 和 CallMethod 的参数类型兼容性
反射调用对参数类型极其严格：实际传入的 reflect.Value 类型必须与函数/方法签名完全一致，包括基础类型别名（如 type MyInt int 和 int 不兼容）、指针层级、是否为接口等。
典型现象：传 reflect.ValueOf(int64(42)) 给只接受 int 的函数 → panic: "cannot use … as …"。
- 优先用
reflect.Value.Convert显式转换（仅当类型底层兼容且可转换时） - 对数字类型，可借助
Int()/Int64()等取原始值再重包，但要注意溢出 - 字符串、切片、map 等引用类型一般无需转换，但注意 nil vs 非nil 判定
- 接口类型参数：传入的
reflect.Value必须是具体实现类型的值，不能是interface{}本身
为什么 reflect.Value.Call 在 HTTP handler 或 RPC 中容易出错
在 Web 框架或 RPC 反射调度中，常因忽略调用上下文导致 panic 或静默失败：比如 handler 函数签名是 func(http.ResponseWriter, *http.Request)，但传入了 nil 的 reflect.Value 或类型不匹配的 request 封装值。
更隐蔽的问题是 recover 机制缺失 —— 一次反射调用 panic 会导致整个 goroutine 崩溃，而 HTTP server 默认不 recover。
- 务必对
Call做defer/recover包裹，尤其在线上服务中 - 提前校验
len(args) == fn.Type().NumIn()和每个arg.Type() == fn.Type().In(i) - 避免在循环中高频反射调用；考虑用
reflect.MakeFunc缓存适配后的函数值 - HTTP handler 场景下，
http.ResponseWriter是接口，传参时要用reflect.ValueOf(w)（w 是具体实现），不能传nil或错误类型
反射调用本身不慢，慢的是每次都要做类型检查和栈准备；真正难调试的是类型不匹配和 receiver 指针丢失 —— 这两类问题不会报编译错误，运行时才暴露，且错误信息模糊。
