Go 高手（10）：接口底层——iface、eface、动态派发

更新时间：2026-09-01。本文是 languages/go/intermediate/ 高手层第 10 篇，接 字符串底层。接口是 Go 类型系统的核心。底层，接口值由类型指针 + 数据指针组成。理解接口的底层实现，才能理解 nil 接口与 nil 指针的区别、动态派发的开销，以及接口断言的本质。

本文要回答的问题

• interface{} 和 interface{...} 在底层有什么区别？
• 为什么一个 nil 指针放到接口里，接口不是 nil？
• 接口的"动态派发"开销有多大？
• 类型断言和类型 switch 的底层是什么？
• 接口值比较时，什么时候相等？

一、eface：空接口的底层结构

var a any
var a interface{}

空接口在底层是 eface（empty interface）：

type eface struct {
    _type *_type     // 指向具体类型的描述信息
    data  unsafe.Pointer  // 指向具体值的指针
}

eface（16 字节）
┌──────────────────────┐
│  _type (8 bytes)     │  → 类型信息（int、string 等）
├──────────────────────┤
│  data (8 bytes)      │  → 指向具体值
└──────────────────────┘

二、iface：带方法接口的底层结构

有方法的接口在底层是 iface：

type iface struct {
    tab  *itab          // 类型 + 方法表
    data unsafe.Pointer  // 指向具体值
}

type itab struct {
    inter *interfacetype  // 接口类型信息
    _type *_type          // 具体类型信息
    hash  uint32          // 类型哈希，用于快速类型断言
    fun   [1]uintptr      // 方法表（函数指针数组）
}

iface（16 字节）
┌──────────────────────┐
│  tab (*itab)         │  → 类型 + 方法表
├──────────────────────┤
│  data (unsafe.Pointer)│  → 指向具体值
└──────────────────────┘

itab 结构：
┌──────────────────────┐
│  inter               │  → 接口类型
├──────────────────────┤
│  _type               │  → 具体类型
├──────────────────────┤
│  hash                │  → 类型断言用
├──────────────────────┤
│  fun[0]              │  → 方法 1 地址
│  fun[1]              │  → 方法 2 地址
│  ...                 │
└──────────────────────┘

itab 的缓存：Go runtime 会缓存 itab，相同的（接口类型，具体类型）组合只创建一次 itab，避免重复构建。

三、nil 接口 vs nil 指针

var p *int = nil
var i any = p

fmt.Println(p == nil)  // true
fmt.Println(i == nil)  // false

为什么 i == nil 是 false？因为 i 的底层结构是：

eface{
    _type: *int,   // 有类型信息
    data: nil,     // 数据指针是 nil
}

接口是 nil 当且仅当 _type == nil 且 data == nil。上面 i 的 _type 不是 nil，所以 i != nil。

// 检查接口是否为 nil 的正确方式
func isNil(i any) bool {
    if i == nil {
        return true
    }
    v := reflect.ValueOf(i)
    return v.Kind() == reflect.Ptr && v.IsNil()
}

四、接口的"动态派发"开销

调用接口方法和直接调用方法有性能差异：

type Reader interface {
    Read([]byte) (int, error)
}

// 直接调用（静态派发）：编译期就知道调用哪个函数
var f *os.File
f.Read(buf)

// 接口调用（动态派发）：运行时从 itab 的 fun 数组里取函数地址
var r Reader = f
r.Read(buf)

动态派发开销：

• 一次额外的指针间接寻址（从 itab 取函数地址）
• 无法内联
• 编译器无法做逃逸分析优化

性能差异：接口调用比直接调用慢 ~5-30%，具体取决于方法大小。在热路径上，这个开销可能显著。

类型断言 vs 类型 switch：

// 类型断言：O(1) 哈希查找
if v, ok := i.(*os.File); ok {
    // 用 v
}

// 类型 switch：逐个比较，O(n)
switch v := i.(type) {
case *os.File:
    // 用 v
case *net.Conn:
    // 用 v
}

类型断言用 itab 的 hash 快速匹配，O(1)。类型 switch 逐个比较，O(n)。如果类型数量多，先断言再 switch 更快。

五、接口值的比较

var a any = int(1)
var b any = int(1)
fmt.Println(a == b)  // true

var c any = []int{1, 2, 3}
var d any = []int{1, 2, 3}
fmt.Println(c == d)  // panic: runtime error: comparing uncomparable type []int

接口值比较规则：

• 先比较 _type，不同则 false
• 再比较 data 指向的值，具体比较方式由 _type 决定
• slice、map、func 不可比较，会 panic

六、常见坑对照

坑	现象	对策
nil 指针放接口里，接口不是 nil	接口 != nil 判断失败	不要把 nil 指针赋值给接口
接口调用比直接调用慢	性能差异	热路径避免接口，用具体类型
不可比较类型放接口里比较	panic	只在确定类型可比较时比较接口
接口值作为参数传递	小值（int）在栈上，大值在堆上	了解接口的装箱/拆箱开销

相关与延伸

下一篇：结构体内存对齐——字段重排、对齐规则、size 优化；接口的隐式实现和类型断言，入门层见 接口 和 类型断言。

一句话总结

Go 接口底层：空接口 eface 是 _type + data，有方法接口 iface 是 itab + data；itab 缓存（接口类型，具体类型）组合，类型断言是 O(1) 的哈希查找；nil 指针放接口里接口不是 nil，因为 _type 不为空；接口调用比直接调用慢，因为动态派发不能内联；接口值比较先比类型再比值，不可比较类型会 panic。