reflect.TypeOf(fn).NumIn()返回函数输入参数个数,需传函数值而非调用结果;变参视为1个参数;method含receiver故NumIn()多1;应避免热路径使用。
reflect.TypeOf 获取函数类型再调 NumIn
Go 的 reflect
包不直接暴露“函数有多少个参数”这种元信息,必须先拿到函数的类型对象,再调它的方法。关键路径是:reflect.TypeOf(fn).NumIn() —— 这返回的是函数类型的输入参数个数。
注意:传给 reflect.TypeOf 的必须是函数值(如变量或字面量),不能是函数调用表达式(比如 reflect.TypeOf(foo()) 会报错,因为那是调用结果)。
NumIn() 返回的是形参个数,包括 receiver(如果是 method);但普通函数没有 receiver,所以就是你写的参数列表长度func(int, string) bool,NumIn() 返回 2
func(...int),NumIn() 仍返回 1(变参被视为一个 []int 类型的参数)reflect.Type.In(i)
知道数量只是第一步,多数场景还需要具体每个参数是什么类型。这时得配合 In(i) 方法,下标从 0 开始。
常见误操作是越界访问 —— 比如对一个 2 参数函数调用 In(2),会 panic。
NumIn() 判断范围,再循环取 In(i)
In(i).Name() 对命名类型(如 type MyInt int)返回 "MyInt";对内置类型(如 int、string)返回空字符串,此时应看 In(i).Kind()
Elem() 或 Field(),不是单次 In() 能覆盖的reflect.Type 行为不同如果你反射的是某个 struct 的 method(比如 obj.Do),reflect.TypeOf(obj.Do).NumIn() 会返回 n+1,其中 n 是你声明的参数个数,多出来的那个是 receiver(即 obj 的类型)。
这容易导致误判。例如:
type Greeter struct{}
func (g Greeter) Say(name string, times int) {}
// reflect.TypeOf(Greeter{}.Say).NumIn() == 3(receiver + name + times)
reflect.ValueOf(fn).Kind() == reflect.Func 且 reflect.ValueOf(fn).Type().NumIn() > 0,再结合 reflect.ValueOf(fn).Type().In(0).PkgPath() 是否为空来推测(receiver 通常无包路径)reflect.ValueOf(fn).Type() 获取类型后,检查其 String() 是否含 "func( 开头而非 "func ((注意空格)—— 但这属于 hack,不推荐用于生产逻辑reflect 查参数reflect 是运行时开销较大的机制,NumIn() 看似轻量,但背后涉及类型系统遍历和接口转换。它只适合初始化、配置解析、测试框架、CLI 参数绑定等低频场景。
真正难处理的其实是 interface{} 参数里藏的函数,或者闭包——它们的 reflect.Type.String() 可能显示为 "func(...)",但无法还原原始签名,这时候只能靠文档或约定。