答案是：空接口 interface{} 底层为 eface（含 _type 和 data），非空接口（如 io.Reader）底层为 iface（含 tab 指向 itab 和 data）；二者结构不同，用途分明。
面试问“Golang 接口底层是 iface 还是 eface”，答案不是二选一，而是看具体接口类型：空接口 interface{} 底层是 eface，非空接口（如 io.Reader、Stringer）底层是 iface。混淆二者，等于没搞清 Go 接口的双重实现机制。
interface{} 对应 eface：只有 _type 和 data
eface 是专为 interface{} 设计的极简结构，只存两样东西：_type（指向类型元信息）和 data（指向值本身）。它不关心方法，也不参与方法调用——因为 interface{} 没有方法约束。
常见错误现象：panic: interface conversion: interface {} is int, not string，本质就是运行时比对 eface._type 和断言目标类型的 *_type 不匹配，找不到转换路径。
- 赋值
var i interface{} = 42时，eface._type指向int的类型描述符，data指向整数 42 的内存地址 - 用
reflect.TypeOf(i)查到的正是eface._type所指内容 - 不能对
interface{}直接调方法，必须先类型断言或反射取出具体值
具名接口对应 iface：tab + data，itab 才是关键
iface 多了一个 tab 字段，它指向 itab 结构体。itab 才是真正干活的：缓存了接口类型、具体类型、哈希值，最关键的是 fun[1]uintptr —— 方法函数指针数组。没有 itab，就无法在运行时动态跳转到具体实现的方法。
常见错误现象：cannot use t (type T) as type Reader in assignment: T does not implement Reader (Read method has pointer receiver)，这不是编译器“不认识”类型，而是构造 itab 时发现 T 的方法集不满足 Reader 要求。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
itab是全局唯一缓存的，相同接口+类型组合只生成一次，避免重复计算 -
tab == nil表示该类型根本没实现这个接口；tab != nil && data == nil是“非 nil 接口但内部指针为 nil”，此时调方法会 panic - 接收者是
*T时，只有&t能触发itab构建；t会失败，编译报错
为什么 nil 接口不等于 nil 指针？
接口变量为 nil，要求两个字段同时为零：eface 需 _type == nil && data == nil；iface 需 tab == nil && data == nil。只要 tab 或 _type 非空，哪怕 data 是 nil，整个接口就不等于 nil。
典型陷阱：
var r io.Reader var buf *bytes.Buffer r = buf // 此时 r.tab != nil, r.data == nil → r != nil r.Read(nil) // panic: nil pointer dereference
- 不要依赖
r == nil来判断底层值是否有效，尤其当接口来自函数返回或结构体字段时 - 检查前先做
if r != nil，再确认r内部的指针是否可解引用（比如buf本身是否为nil） - 结构体中嵌入接口字段时，初始化遗漏会导致
tab已存在但data为空，极易静默崩溃
真正容易被忽略的点在于：iface 和 eface 不是源码里能声明或操作的类型，它们藏在 runtime 内部；所有关于“接口怎么装值”“为什么断言失败”“为啥 nil 判断失灵”的问题，归根结底都是这两个结构体字段状态的组合结果。看汇编或用 unsafe 窥探内存时，偏移量（如 64 位下 data 在 offset 8）也得按结构体布局来算，错一位就全乱。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
