Go接口调用比直接调用慢，因需运行时解包类型信息、查itab取函数指针，引入间接跳转和分支预测失败；高频小开销场景（如百万次/秒Writer.Write）在火焰图中可见runtime.ifaceE2I等占比上升。
Go 接口调用为什么比直接调用慢
因为 Go 的接口值是 interface{} 运行时的二元组（类型指针 + 数据指针），每次方法调用都要查表：先解包类型信息，再从 itab 中取出对应函数指针。这多一次间接跳转，还可能破坏 CPU 分支预测。
实操中，如果某个热点路径每秒调用百万次 Writer.Write，且底层是 *os.File 这类简单类型，那接口开销会真实可见——不是理论值，是 perf 火焰图里能定位到的 runtime.ifaceE2I 和 runtime.tabI2E 占比上升。
- 纯内联函数（如
int + int）完全不走接口，零开销 - 接口调用无法被编译器内联，哪怕方法体只有 1 行
return nil - 空接口
interface{}比非空接口（如io.Reader）开销略高，因后者在编译期能做部分itab预缓存
哪些情况接口开销可以忽略
只要方法本身耗时远大于派发成本（比如网络 IO、磁盘读写、加解密），接口那几十纳秒就毫无意义。别为 http.HandlerFunc 或 json.Unmarshal 的接口层抠毫秒。
典型可忽略场景：
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 中调用
resp.Write—— 底层是 socket write，微秒级起跳 - 数据库驱动用
driver.Rows接口遍历结果 —— 网络往返或内存拷贝占主导 - 日志库接收
fmt.Stringer接口 —— 字符串格式化本身比接口查表贵两个数量级
判断依据很简单：跑 go test -bench=.，把接口实现换成具体类型再比一次，diff 在 1% 以内就不用动。
怎么确认是不是接口在拖慢你的代码
别猜。用 go tool pprof 直接看火焰图里有没有密集落在 runtime.assertE2I、runtime.interfacelookup 或方法名带 (i *T).Method 的栈帧上。
快速验证步骤：
- 加
//go:noinline到待测方法，防止编译器优化掉接口调用路径 - 用
go test -cpuprofile=cpu.out跑基准测试 -
go tool pprof cpu.out→ 输入top看前几项是否含itab相关符号 - 对比：把变量声明从
var w io.Writer = &bytes.Buffer{}改成w := &bytes.Buffer{}，重跑看差异
注意：如果火焰图里 runtime.mallocgc 占比高，那大概率是接口导致的额外堆分配（比如装箱 int 到 interface{}），不是派发慢。
想减接口开销，但又不能丢掉抽象怎么办
核心原则：让编译器“看见”具体类型。不是消灭接口，而是控制它出现的位置和深度。
- 避免在 tight loop 里反复调用接口方法；把循环体提成函数，传入具体类型参数
- 用泛型替代部分接口场景，例如
func Map[T, U any](s []T, f func(T) U) []U比Map([]interface{}, func(interface{}) interface{})快 3–5 倍 - 对高频小对象（如自定义 error、token 类型），考虑用
unsafe.Pointer+ 类型断言绕过接口，但只在 profile 确认瓶颈后才这么做 - 慎用
interface{}做容器，优先用切片或 map 的具体类型版本；map[string]User比map[string]interface{}少两次类型检查
最常被忽略的一点：接口变量本身的赋值也有开销。频繁写 var x io.Reader = getReader()（而 getReader() 返回具体类型）不如直接写 x := getReader()，让类型推导接管。
