在 Golang 中，利用 reflect.TypeOf 获取函数参数信息时，必须首先确认其 Kind 为 Func，再依次调用 NumIn() 和 In(i)。NumIn() 返回输入参数的总个数，In(i) 的索引从 0 开始且不可越界。闭包、匿名函数与普通函数均适用；可变参数按展开后的数量计数；方法表达式（Method Expression）会包含 receiver 参数，而方法值（Method Value）则不包含。
先说几个核心判断：反射在解析函数参数时，最容易踩坑的地方恰好在这里——你以为拿到类型就万事大吉，但实际调用时，类型不匹配、索引越界、receiver 是否计入等问题，都会让程序瞬间 panic。下面我们将关键点逐一拆解。
如何用 reflect.TypeOf 获取函数的参数信息
直接对函数值调用 reflect.TypeOf，得到的是 reflect.Type，但必须是函数类型才能继续检索参数信息。否则——比如传了 nil 或方法值未取地址——Type.Kind() 会返回 Invalid 或非 Func，后续调用 NumIn() 直接 panic。因此实际编码时，必须事先进行类型断言和 kind 检查：
这步检查不能省略，虽然看起来啰嗦，但能有效避免线上事故。
NumIn() 和 In(i) 的边界与索引规则
NumIn() 返回的是函数声明中「输入参数」的个数，不包含 receiver——Go 方法的隐式第一个参数不会计入，除非你反射的是方法表达式而非方法值。In(i) 索引从 0 开始，但 i 必须小于 NumIn()，越界会直接 panic，不会返回 nil 或 error，这一点需要格外留意。
有几个细节需要记住：
- 闭包、匿名函数、普通函数都适用同一套规则，行为完全一致。
- 如果函数包含可变参数（
...T），NumIn()返回的是展开后的数量。例如：func(int, ...string)的NumIn()是 2，In(1)是[]string类型，注意不是string类型——这是初学者最容易混淆的地方。 - 方法表达式（如
(*T).Method）反射后是函数类型，receiver 参数会出现在In(0)；而普通方法值（t.Method）反射后 receiver 已绑定，NumIn()只计入显式参数。
为什么 reflect.ValueOf(fn).Call() 传参失败常与 In() 类型不匹配有关
拿到参数类型只是第一步。真正调用时，reflect.Value.Call() 要求每个 reflect.Value 的类型必须严格等于对应 In(i) 描述的类型——不能是底层相同但命名不同的类型，也不能自动转换。常见错误是把 int 当作 int64 传入，或将 struct 字面量当作指针传入。一旦类型不匹配，运行时直接 panic，且错误信息模糊难查。
安全的做法是：借助 In(i) 构造对应类型的零值，再用 reflect.New().Elem() 或 reflect.ValueOf(&v).Elem() 确保类型完全一致：
这样写虽然多几行，但能保证每次调用都类型正确，不会因为接口签名变化而在运行时意外崩溃。
反射函数参数在实际项目中容易被忽略的细节
函数签名中的命名参数名（例如 func(a int, b string) 中的 a、b）无法通过反射获取——reflect.Type 只保留数量和类型，不保留参数名。如果需要参数名（比如做 HTTP handler 自动绑定），只能依靠 AST 解析源码或添加 struct tag 手动标注，这是反射的一个天然短板。
另外，导出函数和非导出函数的反射行为一致，但有一个坑：如果函数定义在未导入的包中（例如内部测试函数），反射能拿到类型，但 reflect.Value.Call() 可能因 visibility 规则失败。跨 package 调用未导出函数时，runtime 会直接拒绝，即使类型信息已经到手，也无法真正执行。这一点在编写通用框架或插件系统时需格外小心。
