调用reflect.value.call后，返回值个数为len(retvals)，各返回值类型为retvals[i].type()、底层类别为retvals[i].kind()；需先检查isvalid()再取interface()，遍历判断error接口实现，避免重复.type()和.interface()以提升性能。
怎么用 reflect.Value.Call 拿到返回值个数和类型
调用反射函数后，reflect.Value.Call 返回的是 []reflect.Value，不是原始类型，也不能直接用 len() 或 fmt.Printf 看类型——它包装了一层。你得先确认调用成功（没 panic），再遍历结果切片。
- 返回值切片长度就是函数声明的返回值个数，
retVals := fn.Call(args); len(retVals)就是真实数量 - 每个
retVals[i].Type()是第 i 个返回值的反射类型，retVals[i].Kind()才是你常用来做分支判断的底层类别（比如ptr、struct、interface） - 如果函数有命名返回参数，不影响
len(retVals)，该几个还是几个；但若函数 panic，Call会直接 panic，不会返回空切片
interface{} 返回值里藏了 nil 指针，怎么安全取值
当函数返回 interface{}，而实际塞进去的是一个未初始化的指针（比如 *string），用 retVals[0].Interface() 拿出来仍是 nil，但它的 reflect.Value 本身不为 invalid——这时候直接 .Interface() 不报错，但后续类型断言会失败。
- 务必先检查
retVals[i].IsValid()，无效值说明函数返回了未初始化的零值（如 nil interface、nil slice） - 对
interface{}类型，用retVals[i].Elem().Kind()前必须确保它不是 nil，否则 panic；更稳妥的是先retVals[i].IsNil()（仅对 ptr、map、slice、func、chan、unsafe.Pointer 有效） - 常见翻车点：把
reflect.ValueOf(nil)直接传给Call作参数，会导致返回值里混入 invalid value，后续 .Interface() panic
函数返回多个 error，怎么统一提取并判断
Go 习惯在最后返回 error，但有些工具函数或 mock 场景会返回多个 error（比如 func() (int, error, error)）。反射没法自动识别哪个是 “主 error”，得靠索引约定或类型匹配。
- 不要硬编码
retVals[len(retVals)-1]当 error——万一函数返回(error, error)，你取最后一个可能漏掉第一个 - 推荐遍历所有返回值：
for i, v := range retVals { if v.Type().Implements(reflect.TypeOf((*error)(nil)).Elem().Type()) { ... } } - 注意：用
v.Type().Implements判断是否实现了error接口时，必须传入接口类型的反射类型，即reflect.TypeOf((*error)(nil)).Elem()，而不是reflect.TypeOf(error(nil))（后者是 *interface{}）
性能差在哪？哪些操作能省就省
反射本身慢，但最拖慢的往往不是 Call，而是反复调用 .Type()、.Interface() 和类型断言。每次 .Interface() 都触发一次内存分配和类型擦除还原。
立即学习“go语言免费学习笔记（深入）”；
- 避免在循环里对同一
reflect.Value多次调用.Interface()；提前存成局部变量 -
.Type()可缓存，因为同一个函数的返回类型固定；但.Kind()更轻量，适合运行时分支判断 - 如果只是想“转发”返回值给另一个函数，尽量用
reflect.Value切片直接传，别全转成interface{}再拼 slice——reflect.Value.Call输入输出都支持[]reflect.Value
最易被忽略的是：反射调用无法内联、无法逃逸分析优化，哪怕函数体只有两行，一旦走 reflect.Value.Call，整个调用链就脱离编译器优化范围。真要高频调用，宁可代码生成，别硬扛反射。
