必须从 reflect.Method.Type().In(1) 开始获取业务参数类型，跳过接收者；调用前须判 IsValid() 和 Kind() == reflect.Func，且 nil 接口需预先检查，否则预热直接 panic。
怎么用 reflect.Method 拿到方法的参数类型
直接调用 Method 返回的 reflect.Method 对象，它的 Type 字段是方法签名的完整类型（含接收者），不是你想要的“纯参数类型”。必须跳过第一个参数（即接收者）才能拿到业务参数。
-
reflect.Value.Method(i).Type()返回的是带接收者的函数类型，比如func(*MyStruct, string, int) - 正确做法是：先用
reflect.Value.Method(i).Type().In(j)，其中j从1开始（跳过接收者） - 如果方法是值接收者，
In(0)是值类型；指针接收者时In(0)是指针类型 —— 但不管哪种，都要从1起读业务参数
为什么 reflect.Type.Kind() == reflect.Func 后还不能直接 In()
因为不是所有 reflect.Type 都支持 In()：只有函数类型（Kind() == reflect.Func）才支持，但你得先确认它确实是函数类型，否则 panic。常见误操作是把结构体字段类型当成方法类型去调 In()。
- 错误示例：
field.Type.In(0)（field.Type是结构体字段类型，不是函数） - 正确路径：先
value.Method(i)→ 得reflect.Value→.Type()→ 再.In(j) - 调试时可加 guard：
if t.Kind() != reflect.Func { continue }
自动注入预热时，如何避免 panic：nil interface、未导出方法、非导出字段
反射访问未导出方法或字段会返回零值或 panic，尤其在自动扫描+调用场景下极易崩。预热阶段必须显式过滤。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
reflect.Value.Method(i)只返回导出方法（首字母大写），但MethodByName查未导出方法会返回无效reflect.Value，调Call前务必.IsValid()判断 - 接口类型变量为
nil时，reflect.ValueOf(nilInterface).Method(i)会 panic，需先reflect.ValueOf(x).Elem()或判空 - 参数构造时，若某参数类型是未导出 struct，
reflect.New(t).Interface()会成功，但后续传入方法可能因字段不可见而失败 —— 建议预热时只处理导出类型
性能和兼容性：别在 hot path 里反复做 reflect.TypeOf 和 Method 查找
每次调 reflect.TypeOf 或遍历 NumMethod 都有开销，Go 1.21 后尤其明显。预热逻辑应缓存结果，而不是每次请求都重扫。
立即学习“go语言免费学习笔记（深入）”；
- 缓存建议用
sync.Map，key 是reflect.Type的String()（比直接存Type更安全） - 不要缓存
reflect.Value（含状态），只缓存reflect.Type、参数个数、各参数reflect.Type切片 - 注意：不同包里同名 struct 视为不同类型，
String()包含包路径，可直接用作 key
