接口是 Go 里唯一的多态机制，但「接口调用比直接调用慢多少」这个问题，网上的答案从「几乎一样」到「慢十倍」都有，因为它们比的往往不是同一件事：有的把类型断言算进去，有的把装箱分配算进去，有的还开着 -race。本节用同一台机器、同一套基准，把接口调用的四个环节——动态派发、类型断言、itab 查找、装箱——拆开逐个测量，并给出每一条结论对应的源码位置。
本节要回答：一次接口方法调用、一次类型断言、一次装箱各花多少纳秒？itab 在哪里、什么时候被构造？与卷三《Go 语言高级编程》第 8 章的分工是：卷三讲「怎么写汇编、
unsafe的四条 Pointer 规则」，本节只写运行时成本的实测数据与 itab/eface 的运行时实现，不重复那套规则。结论先给：纯派发（indirect call）的开销在 M1 Pro 上约等于直接调用（都在 2.1–2.2 ns）；真正的成本在装箱分配（7.6–8.0 ns 且每次分配 8 字节）和首次 itab 构造（受全局锁保护）。
9.1.1 实验：把四个环节拆开测
复现基线
- Go 版本：
go1.27.0（GOTOOLCHAIN=go1.27.0），对照线go1.26.0 - 机器：Apple M1 Pro，
hw.ncpu=10，内存 32 GiB（sysctl -n machdep.cpu.brand_string、hw.ncpu、hw.memsize） GOMAXPROCS=10（默认）、GOGC=100（默认）、GOMEMLIMIT未设、未开-race- 基准参数：
-benchtime=3000000x（固定迭代数），-count=5，报告区间而非单点
被测程序把「直接调用 / 接口调用 / 类型断言 / 装箱」分成互不干扰的基准。为避免编译器把接口调用内联或去虚化（devirtualization），两个调用点都标了 //go:noinline：
type Adder interface{ Add(int) int }
type Direct struct{ x int }
func (s *Direct) Add(n int) int { return s.x + n }
//go:noinline
func callDirect(s *Direct, n int) int { return s.Add(n) }
//go:noinline
func callIface(a Adder, n int) int { return a.Add(n) }
运行：
GOTOOLCHAIN=go1.27.0 go test -bench=. -benchmem -count=5 -benchtime=3000000x ./...
真实终端输出（截取与本主题相关的行）：
goos: darwin
goarch: arm64
pkg: e91f
cpu: Apple M1 Pro
BenchmarkCallDirect-10 3000000 2.169 ns/op 0 B/op 0 allocs/op
BenchmarkCallDirect-10 3000000 2.172 ns/op 0 B/op 0 allocs/op
BenchmarkCallDirect-10 3000000 2.171 ns/op 0 B/op 0 allocs/op
BenchmarkCallDirect-10 3000000 2.247 ns/op 0 B/op 0 allocs/op
BenchmarkCallDirect-10 3000000 2.225 ns/op 0 B/op 0 allocs/op
BenchmarkCallIface-10 3000000 2.187 ns/op 0 B/op 0 allocs/op
BenchmarkCallIface-10 3000000 2.246 ns/op 0 B/op 0 allocs/op
BenchmarkCallIface-10 3000000 2.184 ns/op 0 B/op 0 allocs/op
BenchmarkCallIface-10 3000000 2.195 ns/op 0 B/op 0 allocs/op
BenchmarkCallIface-10 3000000 2.234 ns/op 0 B/op 0 allocs/op
BenchmarkAssertHit-10 3000000 0.3323 ns/op 0 B/op 0 allocs/op
BenchmarkAssertHit-10 3000000 0.3453 ns/op 0 B/op 0 allocs/op
BenchmarkBoxSmall-10 3000000 2.159 ns/op 0 B/op 0 allocs/op
BenchmarkBoxSmall-10 3000000 2.160 ns/op 0 B/op 0 allocs/op
BenchmarkBoxSmall-10 3000000 2.857 ns/op 0 B/op 0 allocs/op
BenchmarkBoxLarge-10 3000000 8.076 ns/op 8 B/op 1 allocs/op
BenchmarkBoxLarge-10 3000000 7.758 ns/op 8 B/op 1 allocs/op
BenchmarkBoxLarge-10 3000000 9.965 ns/op 8 B/op 1 allocs/op
BenchmarkAssertManyTypes-10 3000000 35.67 ns/op 0 B/op 0 allocs/op
BenchmarkAssertManyTypes-10 3000000 34.17 ns/op 0 B/op 0 allocs/op
BenchmarkAssertManyTypes-10 3000000 34.13 ns/op 0 B/op 0 allocs/op
PASS
ok e91f 1.232s
读法：
- 接口调用 vs 直接调用：2.18–2.25 ns 对 2.17–2.25 ns，落在噪声里。arm64 上一次间接
CALL和一个可预测的返回，代价与直接调用同量级。 - 类型断言命中缓存：0.33 ns，比一次函数调用还便宜——因为断言只是比较两个指针。
- 装箱：
i & 255（0–255）落在runtime.staticuint64s静态数组上，0 次分配；i + 1000触发mallocgc，7.76–9.97 ns 且每次分配 8 字节。这是接口在热路径上真正的成本来源。 - 8 个不同具体类型各断言一次：34.1–35.7 ns，即每次约 4.3 ns。itab 已由编译器在启动期预建，这里量的仍是「查找命中」，不是「构造」。
汇编证据：派发就是「取 itab 第 24 字节 + 间接调用」
把上面的 callIface 抽成一个最小程序，用 go tool objdump 看接口调用编译成了什么：
type Stringer interface{ String() string }
type C struct{}
func (C) String() string { return "c" }
//go:noinline
func use(s Stringer) string { return s.String() }
GOTOOLCHAIN=go1.27.0 go tool objdump -s "main.use" prog
TEXT main.use(SB) /tmp/gbrt4/e91nm2/main.go
main.go:10 0x10009b560 f9400c02 MOVD 24(R0), R2
main.go:10 0x10009b564 aa0103e0 MOVD R1, R0
main.go:10 0x10009b568 d63f0040 CALL (R2)
R0 指向接口值的 itab，R1 是 data 指针。MOVD 24(R0), R2 把 itab 偏移 24 字节处的函数指针取出来，CALL (R2) 间接调用。偏移 24 不是巧合：itab 的布局是 Inter *InterfaceType（8）+ Type *Type（8）+ Hash uint32（4，补齐到 8），所以 Fun[0] 恰好落在第 24 字节。这就是「接口调用」在机器码层面的全部——一次内存读取加一次间接跳转。
9.1.2 源码：itab 与 eface 的运行时实现
接口值的两字布局
空接口和非空接口的内存布局不同，定义在 src/runtime/runtime2.go：
type iface struct {
tab *itab
data unsafe.Pointer
}
type eface struct {
_type *_type
data unsafe.Pointer
}
非空接口第一个字是 *itab，空接口第一个字是 *_type。itab 本身在 Go 1.27 里已经搬进 internal/abi 并改名为 ITab（src/internal/abi/iface.go），runtime2.go:1131 只是一个别名 type itab = abi.ITab：
type ITab struct {
Inter *InterfaceType
Type *Type
Hash uint32 // copy of Type.Hash. Used for type switches.
Fun [1]uintptr // variable sized. fun[0]==0 means Type does not implement Inter.
}
Fun 是变长数组，按接口方法数在后面追加函数指针；Size() 方法（同文件）说明「Fun[0]==0 表示该类型不实现该接口」。这解释了汇编里的偏移 24：Fun[0] 就是 unsafe.Sizeof(ITab{}) 的结果。
getitab：缓存命中走无锁路径，未命中走全局锁
src/runtime/iface.go:getitab 是「接口/类型对 → itab」的唯一入口：
func getitab(inter *interfacetype, typ *_type, canfail bool) *itab {
...
var m *itab
// First, look in the existing table to see if we can find the itab we need.
// This is by far the most common case, so do it without locks.
t := (*itabTableType)(atomic.Loadp(unsafe.Pointer(&itabTable)))
if m = t.find(inter, typ); m != nil {
goto finish
}
// Not found. Grab the lock and try again.
lock(&itabLock)
...
m = (*itab)(persistentalloc(...))
m.Inter = inter
m.Type = typ
m.Hash = 0
itabInit(m, true)
itabAdd(m)
unlock(&itabLock)
finish:
...
}
关键点：查找是无锁的（先 atomic.Loadp 读表指针再线性探测），只有「未命中、要新建」才拿 itabLock。新 itab 用 persistentalloc 分配——不参与 GC，因为 itab 会被全局表长期引用，放进堆里只会增加标记负担。哈希函数是编译器给的现成哈希异或：
func itabHashFunc(inter *interfacetype, typ *_type) uintptr {
// compiler has provided some good hash codes for us.
return uintptr(inter.Type.Hash ^ typ.Hash)
}
装箱：小整数为什么零分配
src/runtime/iface.go:convT64 是 int/uint64 装箱的落点：
func convT64(val uint64) (x unsafe.Pointer) {
if val < uint64(len(staticuint64s)) {
x = unsafe.Pointer(&staticuint64s[val])
} else {
x = mallocgc(8, uint64Type, false)
*(*uint64)(x) = val
}
return
}
staticuint64s 是同文件第 715 行的 var staticuint64s [256]uint64。0–255 的整数装箱直接指向这个全局只读数组，不分配；256 以上才 mallocgc(8, ...)。这正是 BenchmarkBoxSmall（0 次分配）和 BenchmarkBoxLarge（1 次分配、8 字节）差别的来源。空字符串和 nil 切片同理，分别指向 zeroVal[0]。
Go 1.27 的静态 itab 不再有独立符号
src/runtime/iface.go:itabsinit 在启动时把所有预编译的 itab 灌进全局表：
func itabsinit() {
lockInit(&itabLock, lockRankItab)
lock(&itabLock)
for _, md := range activeModules() {
addModuleItabs(md)
}
unlock(&itabLock)
}
// addModuleItabs adds the pre-compiled itabs from md to the itab hash table.
// This is an optimization to let us skip creating itabs we already have.
func addModuleItabs(md *moduledata) {
p := md.types + md.itaboffset
end := p + md.itabsize
for p < end {
itab := (*itab)(unsafe.Pointer(p))
itabAdd(itab)
p += uintptr(itab.Size())
}
}
md.itaboffset / md.itabsize 是 src/runtime/symtab.go 里 moduledata 的新字段（1.27 引入）。它带来一个可以直接观察的差异——用 go tool nm 在二进制里搜 go:itab 符号：
GOTOOLCHAIN=local go tool nm prog126 | grep "go:itab.main.C"
GOTOOLCHAIN=go1.27.0 go tool nm prog | grep -c "go:itab"
1001739f8 R go:itab.main.C,main.Stringer
0
1.26 里 go:itab.main.C,main.Stringer 是一个带名字的数据符号；1.27 里静态 itab 被收进 moduledata 的匿名区域，nm 搜不到了。编译器侧对应的包名仍叫 go.itab（src/cmd/compile/internal/gc/main.go:120：ir.Pkgs.Itab = types.NewPkg("go.itab", "go.itab")），只是链接后不再单独命名。
编译器还会去虚化
src/cmd/compile/internal/devirtualize/devirtualize.go:StaticCall 会把「具体类型静态可知」的接口调用替换成直接调用；同文件第 21 行的 const go126ImprovedConcreteTypeAnalysis = true 表明 1.26 起改进了具体类型分析。这就是为什么微基准里接口调用有时反而「更快」——不是派发变快了，而是那次调用压根没走派发。所以测接口开销必须像上面那样用 //go:noinline 的参数把具体类型藏起来。
9.1.3 决策：什么时候该在意接口
由上面的数据推出一条主线：接口调用的派发本身几乎免费，昂贵的是它附带的内存行为。 据此给出决策表：
| 场景 | 成本量级 | 建议 |
|---|---|---|
| 热路径上按接口调用方法 | 与直接调用同量级（~2 ns） | 不必为了性能把接口拆掉 |
| 每次调用都装箱一个 >255 的整数或结构体 | 7.6–10 ns + 8 B 分配 | 改传具体类型，或复用已装箱值 |
热路径上把 int 当 any 传来传去 | 256 以内免费，以外每次分配 | 小范围枚举值可放心装箱 |
用 any 存大量不同具体类型再反复断言 | 命中 ~0.33 ns，构造一次受全局锁 | 断言本身便宜；别在初始化后才制造大量新 itab |
| 编译器能静态确定具体类型 | 0（被去虚化） | 让具体类型在调用点可见，别过早抽象成接口 |
三条可操作的检查项：
- 先看分配，再看派发。
go test -benchmem里allocs/op非零，优先怀疑装箱而不是接口调用本身。 - 区分「断言命中」和「itab 构造」。 命中是两次指针比较；构造要走
itabLock和persistentalloc。前者可以放心放热路径，后者应尽量在启动期完成（Go 会通过itabsinit自动完成静态 itab）。 - 别用
any当通用容器。 一个存any的切片在装箱时把值复制到堆上，遍历时又要断言取回，成本全在分配与间接寻址，而不是派发指令。
阅读导航：上一节：8.3 内联、边界检查消除与 -gcflags · 下一节：9.2 反射与 unsafe 的运行时成本 。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。