Go中无法通过字符串直接调用方法，必须使用reflect：先reflect.ValueOf(&obj)获取可寻址值，再MethodByName获取导出方法，最后Call传入[]reflect.Value参数并处理返回值，且需注意类型匹配、错误检查与安全限制。
Go 里不能直接用字符串调用方法，得靠 reflect 拼出完整链路
Go 没有 Python 的 getattr(obj, name)() 那种简洁语法。想用字符串名触发方法，必须手动走反射三步：取值 → 取方法 → 调用。而且对象必须是导出（首字母大写）的，方法也必须是导出的，否则 MethodByName 返回 nil。
常见错误现象：MethodByName 返回 nil 或 panic “call of reflect.Value.Call on zero Value”，本质是没拿到有效的 reflect.Value，比如传了非指针、或对象本身不可寻址。
- 确保传入的是指针：
reflect.ValueOf(&obj)，不是reflect.ValueOf(obj) - 检查方法是否导出：函数名必须大写，如
DoSomething，doSomething不可见 - 确认对象类型支持该方法：接口类型需先断言为具体类型，再反射
reflect.Value.Call 要求参数是 []reflect.Value，别直接传原始值
反射调用不接受普通 Go 值，所有参数都得包装成 reflect.Value 列表。漏掉这步会 panic：“invalid memory address or nil pointer dereference” 或 “wrong type for call”。
典型场景：你有一个字符串 "Add" 和两个整数 a=1, b=2，想调用 obj.Add(1, 2)。不能写 method.Call([]interface{}{1,2}) —— 这是错的。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：用
reflect.ValueOf(a)、reflect.ValueOf(b)构造[]reflect.Value - 如果方法无参，传空切片：
method.Call(nil)，不是method.Call([]reflect.Value{})（后者长度为 0 但底层数组非 nil，某些旧版本会出问题） - 注意参数类型必须严格匹配：传
int却期望int64会 panic，必要时用.Convert()
执行后要检查 Call 返回的 []reflect.Value，尤其是错误和返回值
reflect.Value.Call 总是返回一个 []reflect.Value，哪怕原函数没有返回值（此时长度为 0）。如果方法签名含 error，你得自己取出来并判断是否为 nil，Go 不会自动 panic。
容易踩的坑：忽略返回值里的 error，导致后续逻辑静默失败；或误把多返回值当单个值处理。
- 若方法返回
(int, error)，results[0].Int()取结果，results[1].Interface()取 error，再做if err != nil判断 - 用
results[i].IsValid()防止空值 panic（比如方法 panic 导致部分返回值无效） - 不要对
results直接fmt.Println调试 —— 它打印的是反射包装体，看不出真实值，改用.Interface()
性能差且类型不安全，只在配置驱动或插件场景下用
反射调用比直接调用慢 10–100 倍，且绕过编译期类型检查。一旦方法签名变更，运行时才报错，CI 很难覆盖。
真正适合的场景其实很窄：比如从 YAML 加载“动作名+参数”，驱动一组预定义的 handler；或实现简易 RPC 路由（方法名即 endpoint）。
- 替代方案优先考虑 map 映射：
map[string]func() error，启动时注册，快又安全 - 如果必须用反射，建议加一层缓存：
sync.Map存methodName → reflect.Value，避免重复MethodByName - 永远对输入的函数名做白名单校验，防止通过字符串调用任意方法（如
"os.Exit"）
最常被忽略的一点：反射调用无法捕获 panic —— 如果目标方法 panic，它会直接向上冒泡，不会被 recover 在反射层截住。真要兜底，得在目标方法内部处理，或者在外层用 defer/recover 包一层实际调用逻辑。
