go接口底层由itab和_type共同实现：itab是接口与具体类型的契约表，存储方法入口地址；_type是类型元信息，描述类型自身特征；iface用于非空接口，eface用于空接口。
Go 接口的底层实现核心是 itab（interface table）和 _type（类型元信息），它们共同支撑了 Go 的非侵入式接口和运行时类型判断。理解这两者，就抓住了接口动态调用、类型断言、空接口存储等行为的本质。
itab：接口与具体类型的“契约表”
itab 是接口在运行时的关键结构，每个「接口类型 + 具体类型」的组合对应唯一一个 itab（全局缓存，避免重复生成）。它不存储值，只描述“某个具体类型是否实现了某个接口，以及方法怎么找”。
关键字段包括：
- inter：指向接口类型（
*imethod数组）的指针，记录该接口声明了哪些方法（名称+签名） - _type：指向具体类型的
_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 协同生成，开发者不可见但处处受其约束。看懂它们，接口就不再是黑盒。