正确使用 reflect.TypeOf 提取函数签名需调用 Func.In(i) 和 Func.Out(i) 获取参数与返回值类型，注意下标从0开始，且必须校验 NumIn() 和 NumOut()；导出函数才能被反射调用，未导出函数或闭包调用会 panic；参数须用 reflect.ValueOf 包装，类型、数量、顺序须严格匹配；多返回值中 error 位于 results[NumOut-1]，需动态判断；方法调用必须绑定实例，不能直接反射函数值。
如何用 reflect.TypeOf 正确提取函数签名
直接对函数调用 reflect.TypeOf 返回的是 reflect.Func 类型，但它的 String() 输出不直观，不能直接看出参数和返回值类型。必须用 Func.In(i) 和 Func.Out(i) 逐个取——注意下标从 0 开始，且 In(0) 是第一个参数，Out(0) 是第一个返回值。
常见错误是误把函数值传给 reflect.ValueOf 后直接调 Call，却没检查参数数量或类型是否匹配；更隐蔽的问题是：如果函数有多个返回值，其中一个是 error，而你只取了第一个 Out(0)，就可能漏掉错误处理逻辑。
-
Func.NumIn()和Func.NumOut()必须在调用前校验，否则Call会 panic - 导出的函数（首字母大写）才能被反射调用；未导出函数虽能获取类型，但
Call会报call of unexported method - 函数参数若含 interface{}，反射无法自动推断具体类型，需显式构造
reflect.Value并确保底层类型一致
用 reflect.Value.Call 传参时怎么避免 panic
传入 Call 的必须是 []reflect.Value，每个元素对应一个参数，且类型、数量、顺序必须与函数签名完全一致。最常踩的坑是：把原始 Go 值（比如 int、string）直接塞进切片，而没用 reflect.ValueOf 包装；或者包装了但用了指针（&x），而函数期望的是值类型。
另一个关键点：如果函数参数是结构体字段，而该字段未导出（小写），即使整个结构体是导出的，反射也无法访问其字段值，FieldByName 返回零值，后续 Call 极易因类型不匹配崩溃。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有参数必须用
reflect.ValueOf(x)转换，不能传原始值 - 若函数定义为
func(int, *string)，第二个参数必须是reflect.ValueOf(&s)，不是reflect.ValueOf(s) - 可提前用
CanInterface()和CanAddr()判断是否能安全转换或取地址
如何处理多返回值，尤其是 error 类型
反射调用后返回的 []reflect.Value 按函数定义顺序排列，哪怕最后一个返回值是 error，它也只在数组末尾，不会被特殊标记。你得自己根据 Func.NumOut() 知道有几个返回值，再决定取几个、怎么解析。
典型场景是封装通用调用器：需要统一检查最后一个返回值是否为 error 并做处理。这时不能硬编码索引为 results[1]，而应动态取 results[numOut-1]，再用 Interface() 转回 Go 类型判断是否为 nil。
- 用
results[i].Interface()取出真实值，但注意：若原返回值是nilerror，Interface()返回nil，可直接判空 - 若函数返回
(int, error)，但实际 error 非 nil，results[0].Int()仍可读，但业务上通常应优先处理错误 - 避免对
results[i]直接调Int()/String()，先用Kind()校验类型，防止 panic
为什么 reflect.Value.Call 有时静默失败或结果不对
最常被忽略的是函数接收者类型。如果函数是某个结构体的**方法**（哪怕定义在包内），反射调用时必须通过该结构体的实例（reflect.Value）来调，不能直接用函数本身。例如 (*MyStruct).Do 是方法，reflect.ValueOf(MyStruct{}.Do) 是无效的——这得到的是一个函数值，但丢失了接收者绑定，调用时 panic 或行为异常。
另外，Go 的函数类型是“不可比较”的，反射中也不能用 == 比较两个 reflect.Value 是否指向同一函数；只能比对 Type() 或用 Pointer()（需确保是可寻址的）。
- 方法必须绑定到实例：
reflect.ValueOf(&s).MethodByName("Do").Call(args)，而不是reflect.ValueOf(s.Do).Call(args) - 闭包函数无法被反射调用，
reflect.ValueOf(func(){})得到的Call总是 panic - 跨 package 的函数若未导出，
reflect.Value.Call会报call of unexported function，连运行时检查都过不去
反射调用的本质是绕过编译期类型检查，所以所有类型、数量、导出性、接收者绑定都得靠人来守。写一次容易，维护时最容易出问题的地方，往往不是语法，而是某个字段名改了、某个参数加了 tag、或者某次重构把函数挪进了未导出方法里——这些都不会报编译错误，但反射会当场失败。
