反射调用方法前须确保值可寻址且为导出方法，参数类型须严格匹配目标签名，panic需在Call内用defer/recover捕获，动态执行错误应尽早校验。
反射调用方法前，先确认值是否可寻址
直接对 interface{} 或字面量做反射调用，reflect.Value.Call 会 panic：「call of reflect.Value.Call on zero Value」或「cannot call method on nil pointer」。根本原因是反射对象不可寻址，没有底层可修改/可调用的实体。
常见错误场景：传入一个结构体字面量（如 MyService{}）或从 map 取出的值，再用 reflect.ValueOf() 包装后尝试调用其方法 —— 此时得到的是不可寻址的副本。
- 必须用
&obj传地址，再reflect.ValueOf(&obj).Elem()获取可寻址的结构体实例 - 若原始值是指针，需先
.Elem()解引用，否则调用的是指针类型的方法（可能不存在） - 检查
v.CanAddr() && v.CanInterface()是安全调用的前提，缺一不可
方法名匹配区分大小写且必须是导出方法
Go 的反射只能调用导出（首字母大写）方法。即使你写了 func (s *MySvc) handleOrder(...)，反射也找不到它 —— reflect.Value.MethodByName("handleOrder") 返回零值，后续 .Call() 会 panic。
这和编译期可见性一致，不是反射“限制”，而是语言设计使然。运行时无法绕过。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 方法名必须完全匹配，包括大小写：
"Process"≠"process" - 可用
v.NumMethod()和v.Method(i).Type().Name()列出所有可调用方法，调试时很有用 - 如果业务逻辑封装在非导出方法里，要么改名，要么暴露一个导出的调度方法（如
Run(action string, args ...interface{})）
参数传递必须是 []reflect.Value 类型且类型严格匹配
反射调用不支持自动类型转换。哪怕函数定义是 func(id int64)，你传入 reflect.ValueOf(int(123)) 就会 panic：「wrong type for parameter 0」。
这是最容易踩的坑 —— 表面看值一样，底层 reflect.Type 不同。
- 每个参数都必须用
reflect.ValueOf(x).Convert(targetType)显式转成目标方法签名所需类型 - 获取目标方法类型：
method.Type().In(i)，再用reflect.ValueOf(arg).Convert(method.Type().In(i)) - nil 指针参数要特别小心：传
reflect.Zero(reflect.TypeOf((*MyStruct)(nil)).Elem())，而不是reflect.Zero(reflect.TypeOf(&MyStruct{}).Elem())
panic 捕获必须在 Call 后立即做，不能依赖 defer
反射调用内部 panic 不会被外层 defer/recover 捕获，除非你在 Call() 返回的 []reflect.Value 中检查第一个返回值是否为 reflect.ValueOf(&error).Elem() 类型 —— 这不可靠。正确做法是把 Call() 放在 defer/recover 作用域内。
但注意：recover 只对当前 goroutine 有效，且必须在 panic 发生的同一函数中调用。
- 推荐封装一层：
func safeCall(v reflect.Value, method string, args []reflect.Value) ([]reflect.Value, error) - 在该函数内用
defer func() { if r := recover(); r != nil { err = fmt.Errorf("call %s: %v", method, r) } }() - 不要试图在业务方法里 recover —— 反射调用的 panic 已脱离原上下文
动态执行的本质是把类型检查从编译期移到运行时，越晚发现错误，定位成本越高。方法名拼错、参数类型不对、接收者不可寻址 —— 这些问题最好在配置加载阶段就校验，而不是等到请求进来才 panic。
