reflect.value.call 要求参数为 []reflect.value 切片，因反射调用契约强制统一接口；单个 reflect.value 会 panic，且需严格匹配函数签名的类型、数量与顺序。
为什么 reflect.Value.Call 传参必须是 []reflect.Value 而不是单个 reflect.Value
因为 Go 反射的调用契约强制要求参数以切片形式传入，哪怕方法只接受一个参数。直接传 reflect.Value 会 panic：reflect: Call using zero Value argument 或类型不匹配错误。
- 所有被 RPC 调用的方法，其参数必须能从 JSON 解析后转成
reflect.Value，且数量、顺序、类型要严格匹配函数签名 - 如果方法定义为
func(string, int) error，你就得准备好两个reflect.Value：一个reflect.ValueOf("hello")，一个reflect.Value.Of(42)，再一起塞进切片里 - 常见坑：把
json.Unmarshal后的interface{}直接丢给reflect.ValueOf，结果得到的是interface{}类型的值，而不是目标参数类型 —— 必须先做类型断言或用reflect.Indirect剥离指针/接口包装
如何安全地把 map[string]interface{} 参数映射到目标方法的参数列表
JSON-RPC 的 params 字段可能是数组（按序）或对象（按键名），不能硬编码索引或字段名，得动态适配函数签名。
- 用
reflect.TypeOf(fn).In(i)拿到第i个参数的类型，再根据这个类型去params中找对应值：如果是数组，就取params[i]；如果是对象，就用参数名（需提前从结构体 tag 或函数参数名推导）查params["argName"] - 别依赖
runtime.FuncForPC解析函数名参数 —— 没有调试信息时会失败；更可靠的是用go/ast预处理源码（适合构建期），或约定方法第一个参数是context.Context并跳过它 - 空值处理要小心：
nil的interface{}无法直接转成非指针基础类型（如int），得检查是否为nil并赋予零值，或要求客户端显式传null并配合指针类型接收
reflect.Value.Kind() == reflect.Ptr 时为什么不能直接 Call
因为 reflect.Value.Call 只接受「可调用的值」，即函数类型；而 reflect.Ptr 是指针类型，不是函数。你真正想调用的是指针指向的函数值，但 Go 不允许对函数指针做间接调用 —— 函数值本身就必须是 reflect.Func 类型。
- 正确路径是：先用
reflect.Value.Elem()解引用，再判断.Kind() == reflect.Func，然后才能.Call() - 但如果该指针是
*MyService这类结构体指针，而你要调用的是它的方法，就得用reflect.Value.MethodByName("Foo")，不是.Elem().MethodByName—— 否则会丢失 receiver 绑定 - 容易漏掉的检查：
reflect.Value.IsValid()和reflect.Value.CanInterface()，尤其在从 map 取值再转reflect.Value时，无效值会导致后续Callpanic
为什么返回值处理比参数更易出错
因为 JSON-RPC 规范只要求返回 result 或 error 字段，但 Go 方法可能返回多个值（string, int, error），反射不会自动帮你挑哪个是业务结果、哪个是错误。
- 必须约定规则：最后一个返回值必须是
error，其余全部打包进result—— 如果返回两个非 error 值，就得序列化成数组；如果返回结构体，就直接 encode - 别忘了
error是接口类型，reflect.ValueOf(err).IsNil()才算无错误；用== nil判断反射值永远为 false - 性能隐患：每次
Call后都要遍历返回值做Interface()转换，再 JSON 序列化。高频服务建议缓存reflect.Type和编解码器，避免重复反射开销
最麻烦的从来不是怎么调用，而是怎么让错误信息既符合 JSON-RPC 的 error.code/error.message 结构，又不暴露内部 panic 堆栈 —— 这部分得在 recover() 后手动构造，没法靠反射自动完成。
