反射调用方法比接口调用慢20–50倍，因后者仅需itab查表跳转，前者须运行时解析签名、包装参数、检查可调用性等；常见误用是直接对interface{}反射而非先断言类型，且反射调用易因接收者不匹配或canset() false而panic。
反射调用方法比接口断言慢 20–50 倍，不是“略慢”，是数量级差距；高频路径上用 reflect.Value.Call 替代接口调用，等于主动给 CPU 加负重。
为什么 reflect.Value.Call 比接口方法调用慢这么多
两者底层根本不是一回事：
- 接口方法调用走的是
itab查表跳转：编译期就确定好函数地址，运行时只做一次指针解引用 + 偏移计算，开销几乎可忽略 -
reflect.Value.Call要在运行时做一整套动作：解析函数签名、逐个包装参数为reflect.Value、检查可调用性、生成临时栈帧、再跳转——每一步都带类型擦除和边界检查 - 实测数据来自 pprof：在请求处理循环中每秒调用 10k 次方法，用反射版本 CPU 占用直接翻倍，而接口版本几乎不抬升
常见误用场景：把 interface{} 当成“动态对象”硬套反射
比如从 JSON 解析出 map[string]interface{} 后，想调某个字段对应结构体的 Validate() 方法，于是写：
v := reflect.ValueOf(obj)
method := v.MethodByName("Validate")
if method.IsValid() {
method.Call(nil)
}
这其实错了——obj 是 interface{}，reflect.ValueOf(obj) 得到的是接口值本身，不是它背后的结构体。正确做法是先类型断言还原真实类型，再反射或直接调用：
- 如果已知可能类型（如
*User、*Order），用switch v := obj.(type)分支处理 - 如果真要泛化，定义统一接口
type Validatable interface { Validate() error }，让各结构体实现它，后续直接v.(Validatable).Validate() - 别指望反射能绕过接口契约：即使结构体有
Validate方法，但没显式实现Validatable，obj.(Validatable)就失败，而reflect.Value.MethodByName却可能“找到”，但调用时 panic 或行为异常
CanSet() false 和接收者类型不匹配是反射调用最常 panic 的两个原因
这两类错误不会在接口调用里出现，但反射里一碰就崩：
-
reflect.Value.Call要求目标方法的接收者类型必须与反射值完全匹配：若方法是func (u *User) Save()，就必须传*User的reflect.Value，传User会 panic - 调用前必须确认
rv.MethodByName("Save").IsValid()，否则Call()直接 panic:reflect: Call using zero Value - 参数必须是
[]reflect.Value，每个元素类型、顺序、数量必须与方法签名严格一致；返回值也是[]reflect.Value，需手动result[0].Interface()拿出真实值 - 修改值更苛刻：必须传指针，且
rv.Kind() == reflect.Ptr后再rv.Elem()，否则CanSet()永远 false
真正需要反射调用的场景极少：配置驱动的插件加载、极少数无法提前约定接口的胶水代码、调试工具。只要业务逻辑里出现“我得根据字符串名调方法”，第一反应不该是写反射，而是重构出明确接口——那才是 Go 的惯用法。性能只是表象，类型安全、可读性、IDE 支持、静态分析覆盖，才是反射轻易不可替代的代价。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
