Go接口底层由itab和_type共同实现：itab是接口与具体类型的契约表，存储方法入口地址；_type是类型元信息，描述类型自身特征；iface用于非空接口，eface用于空接口。

Go 接口的底层实现核心是 itab（interface table）和 _type（类型元信息），它们共同支撑了 Go 的非侵入式接口和运行时类型判断。理解这两者，就抓住了接口动态调用、类型断言、空接口存储等行为的本质。

itab：接口与具体类型的“契约表”

itab 是接口在运行时的关键结构，每个「接口类型 + 具体类型」的组合对应唯一一个 itab（全局缓存，避免重复生成）。它不存储值，只描述“某个具体类型是否实现了某个接口，以及方法怎么找”。

关键字段包括：

• inter：指向接口类型（*imethod数组）的指针，记录该接口声明了哪些方法（名称+签名）
• _ty

  

  pe：指向具体类型的 _type 结构，标识“这是什么类型”（如 struct{a int}）
• fun[1]：函数指针数组，按接口方法声明顺序排列，每个元素是该类型对应方法的**实际入口地址**（可能经过 wrapper 调整 receiver）

例如：var w io.Writer = os.Stdout，运行时会查找或创建一个 io.Writer 接口 + *os.File 类型对应的 itab，其中 fun[0] 存的是 (*os.File).Write 的真实地址。

_type：类型自身的“身份证”

_type 是 Go 运行时对每种类型的统一描述，所有具名/匿名类型（包括基础类型、struct、ptr、slice 等）在编译期都会生成唯一的 _type 实例。它不依赖接口，是 Go 反射和类型系统的基础。

核心字段有：

• size：类型大小（字节），用于内存分配和拷贝
• kind：类型种类（uint8，如 kindStruct、kindPtr、kindFunc）
• name 和 pkgPath：类型名与包路径，支持反射获取名称
• methods：该类型导出方法的列表（[]uncommonType），含名字、签名、函数指针 —— itab 正是靠它来填充 fun 数组

注意：_type 不包含字段布局细节（那是 structType 等子结构负责），但它是 itab 查找方法实现的源头。

接口值的内存布局：iface vs eface

Go 有两种接口值结构，对应不同使用场景：

• iface：非空接口（含方法），如 io.Reader。内存中占两个机器字：tab *itab + data unsafe.Pointer。其中 tab 指向上面说的契约表，data 指向具体值（可能栈上逃逸到堆）
• eface：空接口 interface{}。结构更简单：_type *_type + data unsafe.Pointer。没有 itab，因为无需方法查找，只需知道“是什么类型”和“值在哪”

赋值时：var i interface{} = 42 → 创建 eface，_type 指向 int 的类型描述；var r io.Reader = bytes.NewReader([]byte{}) → 创建 iface，先查或建 itab，再填 tab 和 data。

类型断言与方法调用：itab 是桥梁

当你写 v, ok := x.(MyInterface)，运行时做的事是：

• 若 x 是 iface：检查其 tab->_type 是否与目标接口能匹配（通过 itab 查找逻辑，本质是方法集子集判断）
• 若 x 是 eface（即 interface{}）：需先根据 _type 找到该类型对 MyInterface 的 itab（可能新建并缓存）
• 成功则返回新 iface，tab 复用或新建，data 指针不变

调用 i.Method() 时，直接通过 i.tab.fun[n] 拿到函数地址，跳转执行 —— 没有虚函数表查找开销，也没有反射成本，是静态绑定好的间接跳转。

不复杂但容易忽略：itab 和 _type 都是只读的全局数据，由编译器和 runtime 协同生成，开发者不可见但处处受其约束。看懂它们，接口就不再是黑盒。