答案是：interface{}底层为eface（含_type和data），非空接口如io.Reader底层为iface（含tab指向itab和data）；二者结构不同、用途分明，空接口无方法表，非空接口依赖itab实现动态派发。
interface{} 对应 eface：只有 _type 和 data
空接口 interface{} 的底层结构是 eface，它只存两样东西：_type（指向类型元信息）和 data（指向值本身）。它不关心方法，也不参与方法调用——因为没方法可调。
常见错误现象：panic: interface conversion: interface {} is int, not string。这不是“类型写错了”就 panic，而是运行时发现 eface._type 指向的是 int 的类型描述符，而断言目标是 string，两者 _type 不匹配，找不到转换路径。
- 赋值
var i interface{} = 42时，eface._type指向int类型信息，data指向整数 42 的内存地址 -
reflect.TypeOf(i)返回的正是eface._type所指内容 - 不能对
interface{}直接调方法，必须先类型断言或用reflect取出具体值
具名接口对应 iface：靠 tab 指向 itab 才能调方法
任何带方法的接口（比如 io.Reader、Stringer）底层都是 iface，它有两个字段：tab（指向 itab）和 data。真正干活的是 itab：里面存了接口类型、具体类型、哈希值，最关键的是 fun[1]uintptr —— 方法函数指针数组。
常见错误现象：cannot use t (type T) as type Reader in assignment: T does not implement Reader (Read method has pointer receiver)。这不是编译器“不认识”类型，而是构造 itab 时发现 T 的方法集不满足 Reader 要求。
立即学习“go语言免费学习笔记（深入）”；
使用 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 b *bytes.Buffer; r := io.Reader(b)，此时 r == nil 为 false（因为 tab != nil），但 r.Read(...) 会 panic：invalid memory address or nil pointer dereference。
-
var r io.Reader→r == nil成立（tab == nil && data == nil） -
var b *bytes.Buffer; r = b→r == nil不成立（tab != nil，即使data == nil） - 这种差异在 HTTP handler、数据库 scan 等场景中极易漏判，导致 runtime panic
什么时候真得看内存布局
绝大多数业务代码完全不需要碰 iface 或 eface 的字段。Go 把接口抽象得足够干净，暴露它们本意是服务运行时，不是给你日常编码用的。
真要介入的场景极少，典型如：
- 写高性能序列化库，想绕过反射直接解包接口头提取
data地址 - 调试 GC 问题，发现某接口变量长期持有一个大对象，但
data字段实际指向已释放内存（说明itab还活着，GC 误判） - 用 cgo 传接口给 C，需手动构造
iface结构体（极危险，不推荐）
别为了“理解原理”去强行操作——unsafe 读取 iface 头部偏移量（比如 64 位下 data 在偏移 8）在 Go 版本升级后可能失效，且无法跨平台保证。
