Golang 接口底层是 iface 还是 eface？

Go语言接口的底层实现并非统一结构，而是根据接口是否包含方法动态选择两种互不兼容的运行时结构：空接口`interface{}`对应`eface`（仅含类型信息和数据指针），非空接口（如`io.Reader`）则使用`iface`（含方法表指针`tab`和数据指针`data`）；二者内存布局不同、语义迥异——`iface`的nil判断依赖`tab`和`data`同时为零，而`eface`的类型有效性取决于`_type`是否为空，这一根本差异正是理解接口行为、避免常见panic（如nil指针解引用）和面试深度考察的关键所在。

面试问“Golang 接口底层是 iface 还是 eface”，不是让你二选一背答案，而是考你是否理解：Go 的接口变量在运行时根本就**不是统一结构**——它根据接口类型（空 or 非空）自动选择 eface 或 iface，二者共存且互不兼容。

interface{} 对应的是 eface，不是 iface

空接口 interface{} 底层永远是 eface 结构体，只有两个字段：_type（指向类型元信息）和 data（指向值）。它不存任何方法，所以无法直接调用方法，只能做类型断言或反射。

• 当你写 var x interface{} = 42，运行时分配的就是 eface 内存布局（2 个指针宽）
• reflect.TypeOf(x) 拿到的其实是 eface._type 字段所指的 *rtype
• 别试图把 eface 当成通用接口基类——iface 和 eface 在内存上不兼容，也不能互相强制转换

非空接口（如 io.Reader）用的是 iface

只要接口定义了至少一个方法，比如 type Reader interface { Read(p []byte) (n int, err error) }，它的变量底层就是 iface 结构体：包含 tab *itab 和 data unsafe.Pointer。

• tab 不是类型指针，而是指向全局唯一的 itab 实例；itab 里才存着 inter（接口类型）、_type（具体类型）、以及方法地址数组 fun[1]uintptr
• 编译期只检查方法集是否满足；运行时第一次赋值时才懒构建 itab（相同接口+类型组合只生成一次）
• 如果方法接收者是 *T，而你传了 T{} 值，iface.tab 构建失败，直接编译报错：does not implement

为什么 var r io.Reader = nil 和 var r io.Reader = (*bytes.Buffer)(nil) 不一样

这是由 iface 的两字段非零判定规则导致的——接口为 nil，必须 tab == nil && data == nil 同时成立。

• var r io.Reader：tab 和 data 都是零值 → r == nil 为 true
• var buf *bytes.Buffer; r = buf：虽然 buf 是 nil 指针，但 tab 已被初始化（对应 *bytes.Buffer 实现 io.Reader 的 itab），所以 r != nil
• 此时调 r.Read(...) 就会 panic：invalid memory address or nil pointer dereference，因为方法调用走 itab.fun[0]，最终解引用了 data（即 nil）

iface 和 eface 都不能直接操作，但能被 unsafe 窥探

它们是 runtime 内部结构，Go 源码中没有公开定义，也不该手动构造。但调试或深度分析时，可通过 unsafe 加偏移读取：

• interface{} 头地址 + 0 是 _type，+ 8（64 位）是 data
• io.Reader 类型接口头地址 + 0 是 tab，+ 8 是 data；再解引用 tab 才能拿到真正的 _type 和方法表
• 这种操作绕过类型系统，极易因 Go 版本升级导致字段偏移变化而崩溃，生产代码严禁使用

真正容易被忽略的点在于：iface 的 tab 是否为空，决定了接口变量是否为 nil；而 eface 的 _type 是否为空，决定了类型断言能否成功——这两个“空”的含义完全不同，混为一谈是绝大多数人掉坑的起点。

以上就是《Golang 接口底层是 iface 还是 eface？》的详细内容，更多关于的资料请关注golang学习网公众号！