接口调用慢在高频小方法（如每秒百万次io.writer.write）的tight loop中，因需三步内存访问+间接跳转，导致runtime.ifacee2i在火焰图凸起；低频或高耗时场景可忽略。
接口调用本身不慢，慢的是你在每秒百万次的 tight loop 里反复调用 io.Writer.Write 这种微耗时方法——这时 runtime.ifaceE2I 在火焰图里会明显凸起，不是理论值，是真实可观测的开销。
怎么确认是不是接口在拖慢你的代码
别靠猜。接口开销是否显著，取决于方法本体耗时和调用频次的比值。高频 + 低耗时 = 开销可见；低频或高耗时 = 开销可忽略。
- 加
//go:noinline到被测方法（比如(*bytes.Buffer).Write），防止编译器优化掉接口路径 - 基准测试中声明为显式接口类型：
var w io.Writer = &bytes.Buffer{}，而不是w := &bytes.Buffer{} - 运行
go test -bench=. -cpuprofile=cpu.out，再用go tool pprof cpu.out查top - 重点看是否出现
runtime.ifaceE2I、runtime.interfacelookup或栈帧里带(i *T).Method的条目 - 如果
runtime.mallocgc占比高，那更可能是装箱（如interface{}(42)）引发的堆分配，不是派发慢
为什么接口调用比直接调用慢
Go 接口值是二元组（tab *itab + data unsafe.Pointer），每次方法调用都要走三步内存访问 + 一次间接跳转：
- 从接口变量读出
tab指针 - 从
tab里读出函数指针（比如tab.fun[0]） - 把
data当作 receiver，跳转执行
这个地址在编译期无法确定，CPU 分支预测器基本失效，尤其在循环中连续调用同一接口方法时。汇编里你会看到类似 call qword ptr [rax+0x8]，而不是直接 call runtime.write。
哪些场景可以安全忽略接口开销
只要方法本体耗时远大于派发成本（几十纳秒），接口层就毫无意义。典型例子：
-
http.HandlerFunc：底层是 socket write，微秒级起跳 -
database/sql.Rows.Next：网络往返或内存拷贝占主导 - 日志库接收
fmt.Stringer：字符串格式化本身比查 itab 贵两个数量级
验证很简单：go test -bench=. 对比接口写法和具体类型写法，diff 在 1% 以内就不用动。
想减开销又不能丢抽象，怎么办
核心不是消灭接口，而是让编译器“看见”具体类型。关键动作有三个：
- 避免在 tight loop 里反复调用接口方法；把循环体提成函数，参数传具体类型（如
*bytes.Buffer） - 用泛型替代部分接口场景，例如
func WriteAll[T io.Writer](w T, data []byte)，编译期生成专有代码 - 对热路径做类型断言：
if bw, ok := w.(*bytes.Buffer); ok { bw.Write(data) }，绕过 itab 查表
注意：泛型 fallback 到接口时仍走动态派发，所以要明确区分 hot path 和 generic fallback。
真正容易被忽略的点是：itab 构建只发生在首次赋值，但每个「接口类型 + 具体类型」组合都独占一个 itab，哪怕两个接口方法签名完全一样也无法复用。还有，func (T) M() 和 func (*T) M() 是两个完全不同的方法集，编译器不会帮你自动取址或解引用——这是编译期契约，不是运行时错误。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
