go interface多态无虚函数表开销，但真实损耗在于运行时间接调用、itab查表、类型断言及内存逃逸；编译器无法内联interface方法，每次调用需解引用itab.fun跳转，且[]interface{}、map[string]interface{}易引发堆分配和gc压力。
go 的 interface 实现多态本身没有“虚函数表跳转”那种传统开销，但真实损耗来自运行时的间接调用、类型元数据查找和内存逃逸——这些在热路径上会明显拖慢性能。
interface 方法调用比直接调用慢在哪
编译器无法对 interface 方法做内联，每次调用都要走 itab.fun 查表 + 间接跳转。对比直接调用：
-
obj.Do()：编译期确定地址，可内联、无跳转 -
iface.Do()：运行时查itab→ 取fun[0]→ 跳转执行，至少多一次指针解引用 - 火焰图里常看到
runtime.itab和runtime.assertI2T占比突增
map[string]interface{} 是性能黑洞重灾区
业务中常用它做通用 payload，但每次取值都要类型断言 + 复制 + 可能逃逸：
-
v, ok := m["amount"].(float64)触发runtime.convT2E装箱 - 若
m本身是堆分配（比如 HTTP body 解析结果），再套一层interface{}就多一次指针层级 - 压测时
mallocgc频次飙升，GC 压力直线上升
interface{} 切片导致隐式逃逸
声明 []interface{} 看似方便，实则强制每个元素都装箱：
ints := []int{1,2,3}; ifaceSlice := make([]interface{}, len(ints))- 循环赋值
ifaceSlice[i] = ints[i]会让每个int逃逸到堆（哪怕原ints在栈上） - 用
go tool compile -m能看到move to heap提示 - 替代方案：用泛型切片
func Sum[T int|float64](v []T) T，零额外开销
为什么 nil interface 不等于 nil 指针
这是最易踩的语义坑，直接影响空值判断逻辑：
-
var x *MyStruct是 nil 指针；var y interface{} = x后，y != nil（因为y包含非空_type和nil data） - 错误写法：
if v == nil { ... }对 interface{} 永远不成立 - 正确检查：
v == nil || reflect.ValueOf(v).IsNil()或更安全的类型感知判断 - 这个差异在 RPC 序列化/反序列化边界尤其危险，容易漏掉空值校验
interface 的损耗不是线性的，而是随实现类型数量、调用频次、逃逸深度呈指数放大。真正要命的往往不是单次调用，而是它让编译器放弃优化——比如阻止内联、禁用逃逸分析、切断类型流信息。这些“看不见”的代价，在 QPS 上万的服务里，比你写的算法还早一步成为瓶颈。
