Go反射调用方法前必须确保接收者为具体结构体类型（如*User或User），且方法名首字母大写导出；需检查method.IsValid() && method.CanCall()再调用，避免panic。
反射调用方法前必须确认接收者类型
Go 的 reflect.Value.Call 只能调用「已绑定接收者」的方法，也就是你得传一个 *struct 或 struct 值本身，而不是随便一个 interface{}。常见错误是直接对 interface{} 变量做 reflect.ValueOf，结果得到的是非可调用的 reflect.Value，一调就 panic：call of reflect.Value.Call on zero Value。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保原始变量不是 nil 指针，且类型是具体结构体（比如
*User），而非未初始化的interface{} - 用
reflect.ValueOf(obj).Elem()获取指针指向的值（如果 obj 是指针）；若 obj 是值类型，直接reflect.ValueOf(obj) - 调用
MethodByName前先检查返回值是否有效：if method.IsValid() && method.CanCall() { ... }
方法名大小写敏感且必须是导出方法
Go 反射只能访问首字母大写的导出方法。哪怕你在 struct 里写了 func (u User) getName() string，reflect.Value.MethodByName("getName") 也会返回零值 —— 不报错，但 IsValid() 为 false，后续 Call 直接 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认目标方法签名是
func (t T) Name(...)形式，且Name首字母大写 - 调试时可遍历所有方法：
for i := 0; i ，快速核对名字和签名 - 别依赖 IDE 自动补全来判断是否导出；
go vet不报，但反射就是看不见
参数类型和数量必须严格匹配
reflect.Value.Call 传入的是 []reflect.Value，每个元素都得是正确类型的 reflect.Value。常见错误是把 int 直接塞进去：method.Call([]reflect.Value{42}) —— 这会 panic：reflect: Call using int as type int。Go 要求你显式包装成 reflect.ValueOf(42)。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有参数必须用
reflect.ValueOf(x)包裹，不能是原始值 - 注意接收者是否是指针：如果方法定义在
*T上，那反射调用时传入的必须是*T类型的reflect.Value，否则CanCall()返回 false - 参数个数不匹配不会编译报错，但运行时 panic：
reflect: Call with too many or too few arguments
性能差、类型不安全，别在热路径用
反射调用比直接调用慢 10–100 倍，因为要动态解析方法表、校验权限、打包参数、解包返回值。更麻烦的是它绕过了编译期类型检查 —— 方法名写错、参数类型错、甚至方法被重命名，都只在运行时报错。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 仅用于配置驱动的插件系统、RPC 方法分发、测试 mock 等明确需要动态性的场景
- 避免在 for 循环或高频 HTTP handler 里反复做
MethodByName；提前缓存reflect.Value或用 map[string]func(...) 映射 - 上线前务必加单元测试覆盖所有可能的 method name 输入，防止拼写错误漏到生产环境
真正难的不是怎么写反射调用，而是想清楚：这个逻辑是不是非得靠名字字符串来触发？很多时候接口+注册表更稳、更快、更容易 debug。
