Method.Call 比直接调用慢几十倍是因为每次调用都要走完整动态调用链：查方法表、校验接收者、复制参数切片、分配栈帧、类型转换、拆包返回值，且无法被编译器内联或优化。
Method.Call 为什么比直接调用慢几十倍
不是“语法糖没优化好”，而是每次 Method.Call 都得走完整动态调用链：查方法表 → 校验接收者有效性 → 复制参数切片 → 分配临时栈帧 → 执行类型转换 → 拆包返回值。这些动作全在运行时做，编译器无法内联或消除。
实测数据：对一个带 2 个 int 参数的简单方法，Method.Call 比直接调用慢约 35 倍；若参数含 interface{} 或嵌套 struct，慢 60 倍以上，GC 压力同步上升。
-
Method.Call底层调用callReflect，绕过所有编译期函数绑定，每次都要重做类型兼容性检查 - 参数切片
[]reflect.Value必须新分配，哪怕只传 1 个int，也触发堆分配 - 返回值是
[]reflect.Value，取rets[0].Interface()又是一次接口值构造 + 逃逸分析重判
参数装箱的三个易错点
你以为只是 reflect.ValueOf(arg) 包一层？实际每一步都可能 silently 失败或 panic。
- 接收者必须显式传入：用
reflect.ValueOf(&obj)，而非reflect.ValueOf(obj)—— 否则指针接收者方法直接IsValid()为 false - 参数数量必须严格匹配：
method.Type().NumIn()得等于len(args)，少一个或多个都会在Call()时 panic - 参数类型不能“看起来像”就行：
int不能传int64，哪怕值相等；string不能传fmt.Stringer，AssignableTo()检查会失败
缓存 Method 能省多少开销
MethodByName 是反射调用里最贵的环节之一——字符串哈希 + 线性遍历方法表，每次调用都重复执行。缓存 reflect.Method 或其 reflect.Value 能砍掉这部分成本。
- 缓存
reflect.Method（结构体）本身几乎零开销，它不含实例状态，可全局复用 - 更推荐缓存
reflect.Value（即v.MethodByName("Foo")的结果），但前提是接收者稳定（如单例对象或长期存活指针） - 别缓存
reflect.ValueOf(instance)—— 它绑定了具体内存地址，容易导致 GC 无法回收，或后续访问 dangling pointer
真正高频场景该怎么做
如果每秒调用上千次 Method.Call，光靠缓存治标不治本。关键是要把反射挪出热路径。
- 初始化阶段用
reflect.Value.MethodByName获取方法，然后用reflect.MakeFunc包装成普通函数闭包，后续调用走纯函数路径 - 字段级操作优先用
v.Field(i)而非v.FieldByName("x")，前者是数组下标，后者是 O(n) 字符串比对 - 对固定类型结构体，用
unsafe.Offsetof预算字段偏移，生成无反射的 setter/getter 闭包 —— 这才是 p99 延迟能压到微秒级的做法
反射不是不能用，而是别让它出现在你 profiler 里 top 3 的火焰图位置。一旦看到 callReflect 占比高，说明该把反射逻辑从请求处理循环里摘出去了。
