interface{}底层为eface（含_type和data），非空接口如io.Reader底层为iface（含tab指向itab和data）；二者结构不同、用途分明，空接口无方法表，非空接口依赖itab实现动态派发。
Go 接口变量不是指针也不是值，而是一个**带类型信息的二元组**；空接口 interface{} 和非空接口（如 io.Writer）在底层用完全不同的结构存储——前者是 eface，后者是 iface。这个区别直接影响类型断言性能、内存布局、nil 判断逻辑，甚至 panic 原因。
为什么 interface{} 和 io.Reader 的底层结构不同
Go 编译器和运行时根据接口是否含方法，静态选择两种结构：
-
eface仅用于interface{}：无方法约束，只需记录“是什么类型”和“值在哪”，结构固定为两个指针（_type+data） -
iface用于所有含方法的接口：必须支持动态方法调用，所以需要额外的itab表来存方法地址。即使接口只有一个方法（如Stringer），也走iface - 编译期就决定用哪种结构，无法混用。写
var x interface{} = os.File{}用的是eface；写var w io.Writer = &os.File{}用的是iface
nil 接口变量不等于 nil 底层指针
这是最常踩坑的地方：一个接口变量值为 nil，不代表它的 data 字段是 nil，也不代表它的 _type 或 tab 是 nil。
-
var x interface{}→eface{ _type: nil, data: nil }，此时x == nil成立 -
var w io.Writer = (*os.File)(nil)→iface{ tab: *itab, data: nil }，但tab非空（因为*os.File确实实现了io.Writer），所以w == nil为false，但调用w.Write(...)会 panic: "nil pointer dereference" - 判断是否真正可安全调用，不能只看
== nil，而要看data是否为空且tab/_type是否有效——通常应避免让iface的data为nil
itab 是方法派发的关键，但不是每次调用都查表
itab 存在的意义，是让 Go 运行时能在不知道具体类型的情况下，找到对应方法的入口地址。但它不是纯运行时计算出来的：
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
立即学习“go语言免费学习笔记（深入）”；
-
itab在程序初始化阶段或第一次赋值时生成并缓存（全局itabTable），后续相同类型+接口组合直接复用 - 方法调用时，Go 编译器会把
iface.m()编译成类似((*itab.fun[0])(iface.data, ...))的直接函数指针调用，不查哈希表、不反射 - 但类型断言
v, ok := i.(T)会查itab.hash加速匹配；如果断言失败，ok为false，不会 panic - 注意：
itab大小不固定（因fun是变长数组），64 位下最小 40 字节，比eface（16 字节）重得多
什么时候该关心 eface 和 iface 的区别
绝大多数业务代码不需要碰到底层结构，但以下场景绕不开：
- 做高性能序列化/反序列化（比如自定义
encoding.BinaryMarshaler实现），需理解data指针指向的是栈还是堆，是否需要unsafe复制 - 调试奇怪的 panic，比如 “invalid memory address” 却没看到明显 nil 解引用——很可能是
iface的data为 nil 但tab有效 - 写通用工具函数（如 deep-copy、type switch 分支优化），需区分
interface{}和具体接口的行为差异 - GC 调优时：大量短生命周期
iface可能因itab缓存和更大内存占用，比eface更影响分配压力
真正容易被忽略的，是 iface 的 data 字段可以合法地为 nil——而它看起来并不 nil。
