反射调用函数前必须确保接口已导出，即函数或方法名首字母大写；结构体字段若需反射设置也须导出；配置命令需预注册映射表并校验存在性；参数须转为[]reflect.Value；须用recover捕获panic并统一错误处理。
反射调用函数前必须确保接口已导出
Go 的 reflect.Value.Call 只能调用导出（首字母大写）的函数或方法，哪怕你用 reflect.ValueOf(&obj).MethodByName("do") 找到了方法，如果 do 是小写，运行时直接 panic：reflect: Call of unexported method。
常见错误现象：配置里写了 "command": "process"，代码里也定义了 func (t *Task) process() {}，但反射调用失败。
- 所有要被反射调用的函数、方法名必须首字母大写
- 结构体字段同理——如果想通过反射设置字段值，该字段也必须导出
- 别指望用
reflect.Value.UnsafeAddr()绕过限制，它不解决可调用性问题
配置中的函数名到 reflect.Value 的安全映射
不能直接用 reflect.ValueOf(funcMap[cmdName])，因为配置项是字符串，而 Go 没有全局函数注册表；你需要预先构建一个映射表，并做存在性检查。
使用场景：YAML 配置中写 action: "SendEmail"，程序需动态调用对应函数。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
map[string]func(...interface{})或map[string]reflect.Value预注册合法命令，启动时校验完整性 - 从配置读出的字符串必须先查表，不存在就立刻报错（比如
"unknown command: PingDB"），不要等到Call时才 panic - 避免用
eval式拼接函数名（如reflect.ValueOf(eval("Send"+cfg.Type+"Email"))），Go 不支持运行时符号解析
传参时 interface{} 切片不能直接 Call
reflect.Value.Call 接收的是 []reflect.Value，不是 []interface{}。常见错误是把 JSON 解析出的 []interface{} 直接塞进去，结果 panic：reflect: Call using []interface{} as type []reflect.Value。
性能影响：每次调用都要手动转换参数，但这是必须开销，无法绕过。
- 用
reflect.ValueOf(arg).Convert(reflect.TypeOf((*int)(nil)).Elem())这类方式逐个转类型太重，优先用已知目标签名构造参数 - 更稳妥的做法：定义统一入参结构体（如
type CmdArgs struct { Data map[string]interface{} }），让所有命令函数接收该结构，再在内部做类型断言 - 如果必须泛型传参，写个辅助函数：
toReflectValues(args []interface{}) []reflect.Value，里面对每个arg调用reflect.ValueOf(arg)
反射执行后如何捕获 panic 并转为错误
被反射调用的函数一旦 panic，会直接终止整个 goroutine，除非你在 Call 外层用 recover 捕获。但注意：reflect.Value.Call 返回的是 []reflect.Value，其中可能包含 error 类型的返回值，也可能触发 panic —— 两者要分开处理。
容易踩的坑：只检查返回值里的 error，却忽略函数本身 panic 导致的崩溃。
- 必须用
defer func() { if r := recover(); r != nil { /* 转成 error */ } }()包裹Call调用 - 如果函数签名含
error返回值，记得用errI := results[len(results)-1].Interface()拿出来判断是否为非 nil - 别在反射调用链里嵌套 recover —— 比如命令函数自己 recover 了，上层就收不到 panic，但你也失去了统一错误上下文
复杂点在于：你要同时处理「函数返回 error」、「函数 panic」、「反射调用参数不匹配」三种失败路径，且它们的错误信息格式完全不同。配置驱动的命令模式越灵活，这里的错误归一化就越不能省。
