Go反射调用参数类型不匹配会运行时panic，因Call()要求参数底层类型与方法签名逐字节一致；需严格按method.Type().In(i)构造reflect.Value，注意指针、别名、接口和变参处理。
Go反射调用时传参类型不匹配会 panic
直接 panic，不是编译错误，是运行时报 reflect: Call using x as type y 或类似提示。根本原因是：Go 反射的 Call() 方法要求每个 reflect.Value 参数的底层类型必须和目标方法签名**逐字节一致**——包括是否为指针、基础类型别名（如 type UserID int 和 int 不兼容）、甚至接收者是值还是指针。
- 常见错误：把
int64当int传、把string直接塞进[]reflect.Value却没用reflect.ValueOf()包装 - 更隐蔽的坑：函数定义是
func(*MyStruct) Foo(x *string)，你却传了reflect.ValueOf("hello")（值），而非reflect.ValueOf(&s)（指针） - 不定参数（
...T）必须传一个[]T切片的reflect.Value，不能拆成多个独立reflect.Value
如何安全构造参数切片
核心原则：先看方法签名，再按顺序构造每个 reflect.Value，且必须严格对齐。
- 用
method.Type().In(i)获取第i个参数的真实类型（reflect.Type），而不是靠猜测或配置 - 对原始值
v，用reflect.ValueOf(v).Convert(paramType)强制转换（仅当可转换时，如int→int64）；不可转换则需手动适配（如int→*int：先取地址再包装） - 若参数是接口类型（如
io.Reader），确保传入的值实现了该接口，且reflect.ValueOf()封装的是该值本身，不是其底层类型 - 处理不定参数时，先判断
method.Type().IsVariadic()，再用method.Type().In(n-1).Elem()拿到T类型，最后把你的元素切片整体转为reflect.ValueOf(slice)
为什么不能直接用 map 或 []interface{} 解包传参
因为 Go 的类型系统在反射层面不保留“语义”，map[string]interface{} 或 []interface{} 里的值经过 reflect.ValueOf() 后，其 Type() 是 interface{}，无法自动匹配到具体方法所需的 *User 或 []byte。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 主程序从 JSON 解析出
map[string]interface{}，插件期望func(*Config)→ 必须显式构造&Config{...}再reflect.ValueOf() - 缓存里存的是
interface{}，取出后直接reflect.ValueOf(cached)传给方法 → 类型丢失，大概率 panic - 绕过方式：让插件约定接收一个
map[string]interface{}参数，内部自己做字段映射和类型断言，把类型适配逻辑下沉到插件侧
高频反射调用必须缓存 Method 和 Type
每次 reflect.ValueOf(obj).MethodByName("Foo") 或 reflect.TypeOf(obj).Method(i) 都有明显开销，且重复解析类型信息容易掩盖真实类型不匹配问题。
立即学习“go语言免费学习笔记（深入）”；
- 缓存
reflect.Method和其Type().In(i)结果，避免每次调用都重新查签名 - 对固定结构体字段赋值，优先缓存
reflect.Value.FieldByName("X").Addr()得到的可设置reflect.Value，而非每次都FieldByName+Addr - 如果性能敏感，且方法签名稳定，考虑用
reflect.MakeFunc生成一次性的闭包函数，把类型检查提前到生成阶段
最易被忽略的一点：反射调用前不校验 CanInterface() 和 CanAddr() —— 特别是当参数来自 JSON 解析或 HTTP body 时，原始值可能不可寻址，导致后续 Convert() 或 Addr() 失败。务必在封装前确认值的状态。
