接口的两副面孔：eface、iface 与动态派发之谜
var x any = 42 和 var s Shape = rect{} 看起来是同一种语法，但 Go 运行时为它们准备了两套不同的底层结构。今天拆开看看，顺便解开"nil 接口不等于 nil"这个坑了无数人的谜题。
先看全家福：两种接口值
go
// runtime/runtime2.go（简化）
type eface struct { // 空接口 interface{} / any 的底层
_type *_type // 动态类型的完整描述
data unsafe.Pointer // 指向动态值
}
type iface struct { // 非空接口（带方法）的底层
tab *itab // 接口×动态类型的组合信息 + 方法表
data unsafe.Pointer // 指向动态值
}都是 16 字节，都是一个二元组：(类型信息, 值地址) 。区别在于第一个字段------空接口只需知道"你是什么类型"，存 _type 就够；非空接口还要回答"你的方法怎么调"，所以存 itab。
itab：接口与具体类型之间的适配层
itab（interface table）是动态派发的核心：
go
type itab struct {
inter *interfacetype // 接口类型, 如 Shape
_type *_type // 动态类型, 如 Rect
hash uint32 // 类型哈希副本, 断言时快速比对
_ [4]byte
fun [1]uintptr // 方法表(变长), 按方法名排序的函数地址
}三个关键事实：
- 全局缓存 ：
(Shape, Rect)这个组合的 itab 全程序只构建一次，之后所有Shape = Rect{...}的赋值都复用它； - 方法表即跳转表 ：
s.Area()编译后大致是tab.fun[0](data)------查表取地址再间接跳转，这就是接口调用比静态调用贵一点点的原因； - 构建时机：编译期能确定的就静态生成，反射等运行期场景才动态构建（构建失败会 panic）。
动手验证：把接口拆给你看
go
package main
import (
"fmt"
"unsafe"
)
// Shape 非空接口: 带方法的接口, 底层用 iface 表示
type Shape interface {
Area() float64
}
type Rect struct{ W, H float64 }
func (r Rect) Area() float64 { return r.W * r.H }
// eface/iface 镜像结构, 仅用于观察内存布局
type eface struct {
typ unsafe.Pointer // 动态类型描述
data unsafe.Pointer // 动态值地址
}
type iface struct {
tab unsafe.Pointer // itab: 接口类型 + 动态类型 + 方法表
data unsafe.Pointer
}
func main() {
// 1. 空接口 any -> eface, 16 字节
var e any = 42
fmt.Printf("1. unsafe.Sizeof(any) = %d bytes\n", unsafe.Sizeof(e))
ef := (*eface)(unsafe.Pointer(&e))
fmt.Printf(" typ = %p, data = %p, 动态值 = %d\n", ef.typ, ef.data, *(*int)(ef.data))
// 2. 非空接口 -> iface, 也是 16 字节, 首字段是 itab
var s Shape = Rect{W: 3, H: 4}
fmt.Printf("2. unsafe.Sizeof(Shape) = %d bytes\n", unsafe.Sizeof(s))
if_ := (*iface)(unsafe.Pointer(&s))
fmt.Printf(" itab = %p, data = %p, s.Area() = %.1f\n", if_.tab, if_.data, s.Area())
// 3. 同一 (接口, 动态类型) 组合的 itab 全局复用
var s1 Shape = Rect{W: 1, H: 1}
var s2 Shape = Rect{W: 2, H: 2}
t1 := (*iface)(unsafe.Pointer(&s1)).tab
t2 := (*iface)(unsafe.Pointer(&s2)).tab
fmt.Printf("3. 两个 Shape(Rect) 的 itab 相同: %v\n", t1 == t2)
// 4. 指针赋接口: data 直接存指针, 无装箱拷贝
r := Rect{W: 5, H: 6}
var sp Shape = &r
fmt.Printf("4. 指针赋接口: sp.Area() = %.1f\n", sp.Area())
// 5. nil 接口 vs 装 nil 指针的接口
var nilEface any
var nilPtr *Rect
var wrappedNil any = nilPtr
fmt.Printf("5. nilEface == nil: %v\n", nilEface == nil)
fmt.Printf(" wrappedNil == nil: %v\n", wrappedNil == nil)
// 6. 类型断言只比对类型, 不看值
v, ok := wrappedNil.(*Rect)
fmt.Printf("6. wrappedNil.(*Rect): ok = %v, v = %v\n", ok, v)
}运行输出：
text
1. unsafe.Sizeof(any) = 16 bytes
typ = 0x5be3560, data = 0x5bd7288, 动态值 = 42
2. unsafe.Sizeof(Shape) = 16 bytes
itab = 0x5bfe878, data = 0x5bd73c8, s.Area() = 12.0
3. 两个 Shape(Rect) 的 itab 相同: true
4. 指针赋接口: sp.Area() = 30.0
5. nilEface == nil: true
wrappedNil == nil: false
6. wrappedNil.(*Rect): ok = true, v = <nil>逐条解读
第 1~2 行 ：两种接口都是 16 字节。注意 data 指向的不是原始值------42 被装箱 （boxing）拷贝到了一块新内存里，data 指向那份拷贝。
第 3 行 ：两个不同的 Rect 值赋给 Shape，取出的 itab 指针完全相同------缓存复用，实锤。
第 4 行 ：赋指针时 data 直接存这个指针，省掉一次装箱拷贝。推论很直接：热路径上优先传指针，大结构体按值赋接口意味着每次都拷贝整个结构体，还会触发逃逸到堆。
第 5 行 ：经典陷阱现身。wrappedNil 装的是一个 nil 的 *Rect，但它不等于 nil------因为接口判 nil 的充要条件是 typ 和 data 都为 nil。装了具体类型后，typ 字段已经有内容了。
第 6 行 ：类型断言只看类型描述符是否匹配，跟值是不是 nil 毫无关系。所以装着 nil 指针的接口断言照样 ok=true，拿到一个 nil 指针。
nil 陷阱的实战守则
这个坑最常见的形态：
go
func query() error {
var err *MyError
if somethingWrong {
err = &MyError{msg: "boom"}
}
return err // 没出错时返回的是 (typ=*MyError, data=nil), 不是 nil!
}
if err := query(); err != nil { // 永远为 true, 拦不住
...
}守则：返回接口类型时，出错分支之外的路径直接 return nil，不要返回一个可能是 nil 的具体类型变量。
装箱的连锁反应
值进接口 → 拷贝到新内存 → 原值逃逸到堆。三件事一起发生。用 go build -gcflags='-m' 能看到 moved to heap 的记录。这也解释了为什么 fmt.Println(x) 这种参数是 ...any 的调用在热点循环里要尽量回避------每次都有一次装箱。
小结
| 认知 | 一句话 |
|---|---|
| 结构 | 空接口 eface{typ, data}；非空接口 iface{itab, data}，均 16 字节 |
| itab | (接口×类型) 组合全局缓存，方法表支撑动态派发 |
| 装箱 | 值赋接口必拷贝，热路径传指针 |
| 断言 | 只比类型描述符，不看值 |
| nil 判定 | typ、data 双 nil 才是 nil；返回错误接口直接 return nil |