Go反射动态调用核心难点是参数安全传递：MethodByName返回零值主因是方法未导出或接收者类型不匹配；参数须逐个reflect.ValueOf包装，不可整体转换；调用前必检IsValid()和CanCall()，返回值需按Kind判空再取值。
Go 反射在动态任务调度系统中做参数传递，核心难点不是“能不能传”，而是“怎么让传进去的值不 panic、不出错、不丢精度、不越界”。绝大多数调度系统崩溃或行为异常，都卡在参数反射包装这一步。
MethodByName 返回零值？先查接收者和导出性
动态调度时经常要根据字符串名调用 Task.Run 或 Job.Execute，但 MethodByName 一调就返回零值，Call 直接 panic。原因几乎总是两个：
- 方法名首字母小写（如
run），Go 反射只暴露导出成员，非导出方法在reflect.Value中不可见 - 传入的是值类型而非指针：定义为
func (t *MyTask) Run()，却用了reflect.ValueOf(MyTask{})；必须用reflect.ValueOf(&task)才能绑定指针接收者
别依赖日志打 “method not found” 就去改名字——先用 rv.NumMethod() 看看实际有多少方法被反射识别出来，再用 rv.Method(i).Type().String() 打印签名核对。
参数切片必须逐个 reflect.ValueOf，不能整体转
调度系统常从 JSON 或数据库读取参数列表，比如 []interface{}{"hello", 123, true}，然后想一股脑传给 func(task string, id int, active bool)。直接 reflect.ValueOf(args) 包一层，Call 必 panic：“too many arguments”。
立即学习“go语言免费学习笔记（深入）”；
正确做法是手动展开：
args := []interface{}{"hello", 123, true}
paramVals := make([]reflect.Value, len(args))
for i, a := range args {
paramVals[i] = reflect.ValueOf(a)
}
result := fn.Call(paramVals)
注意：如果函数参数是 *string，你得确保传进来的是 &s 的地址，而不是 s 本身；否则 reflect.ValueOf(s) 得到的是 string 类型，和 *string 不匹配。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
结构体字段赋值前务必检查 CanSet
很多调度系统支持“模板化任务”，比如用 map[string]interface{} 填充 type EmailTask struct { To, Subject string; DelaySeconds int }。用反射逐字段赋值时，容易忽略可设置性：
- 未导出字段（首字母小写）
CanSet() == false，强行SetString会 panic - 字段是嵌套结构体或 slice，不能直接
Set，得用SetBytes或遍历元素赋值 -
reflect.ValueOf(task).FieldByName("To").SetString("a@example.com")前，必须确认task是可寻址的（即传的是&task或task是变量而非字面量）
安全写法：
fv := rv.FieldByName(fieldName)
if !fv.IsValid() || !fv.CanSet() {
continue // 跳过不可设字段
}
fv.SetString(value)
返回值处理别硬断言，用 Kind 判断再取值
调度系统需要统一捕获任务返回结果，比如 func() (int, error)。Call 返回 []reflect.Value，但直接 results[1].Interface().(error) 很危险——如果函数没返回 error（比如 panic 了），或者 error 是 nil，Interface() 可能 panic。
更稳妥的方式：
- 先检查
results[i].Kind()是reflect.Interface还是reflect.Ptr - 再用
.IsNil()判断是否为空 - 最后用
.Interface()拿值，或用.Elem().Interface()解包指针
例如 error 处理：
errVal := results[1]
if !errVal.IsNil() {
err := errVal.Interface().(error)
// 处理 err
}
真正容易被忽略的是：当任务函数本身 panic，Call 不会返回，而是直接崩掉整个调度 goroutine。生产环境必须用 recover 包一层，且 recover 后的 error 也要走同样的反射解析路径——否则你永远不知道是参数错，还是任务逻辑崩了。
