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。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 建议先用
NumIn()判断范围，再循环取In(i) -
In(i).Name()对命名类型（如type MyInt int）返回"MyInt"；对内置类型（如int、string）返回空字符串，此时应看In(i).Kind() - 结构体字段、切片元素等嵌套类型需递归调用
Elem()或Field()，不是单次In()能覆盖的
method 和 function 的 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）
- 若想排除 receiver，需先判断是否为 method：用
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 参数绑定等低频场景。
- 高频调用（如 HTTP handler 内部每次请求都查）会导致明显 GC 压力和延迟上升
- 编译期已知参数数量时，应直接硬编码或用泛型约束（Go 1.18+），而不是反射
- 跨 package 的函数若被内联或逃逸分析优化，反射行为不变，但类型信息仍完整；这点比某些语言更可靠
真正难处理的其实是 interface{} 参数里藏的函数，或者闭包——它们的 reflect.Type.String() 可能显示为 "func(...)"，但无法还原原始签名，这时候只能靠文档或约定。
