interface{} 底层是 eface，含 _type 和 data 两字段，无 itab；_type 为 nil 时 eface 无效，值类型赋值拷贝地址，指针赋值存指针值，传参复制指针而非数据。
interface{} 的底层确实是 eface，不是 iface
Go 编译器对 interface{}（或 any）做静态判别：只要接口没声明任何方法，就强制走 eface 路径。它不查方法集、不生成 itab、不缓存匹配表——结构体只有两个字段：_type 和 data。
常见错误现象：
- 误以为
var x interface{} = nil和var w io.Writer = nil是同一类“空”，结果后者可能 panic； - 用反射读
reflect.ValueOf(x).Kind()时返回Invalid，却不知道这是因为_type == nil导致整个eface无效，而非值本身为空。
关键点：
-
_type为nil时，data无论是否为nil，该eface都不可用（比如不能调用reflect.Value.Kind()）； - 赋值
int、string、[]byte等值类型时，data指向栈/堆上的副本地址，不是原变量地址； - 赋值指针（如
*os.File）时，data直接存该指针值，不额外解引用。
为什么 eface 没有 itab 字段
itab 的唯一作用是支撑动态方法调用：给定一个 iface 变量，运行时靠它找到 Write 或 Read 的函数地址。而 interface{} 不承诺任何方法，自然不需要方法表。
这带来三个实际影响：
- 内存更轻：64 位下
eface固定 16 字节（两个指针），iface至少 40 字节（含变长fun数组）； - 赋值更快：无需查找或生成
itab，直接拷贝_type和data； - 类型断言更慢：没有
itab.hash加速，v, ok := x.(string)需遍历全局类型表比对_type。
eface 的 _type 字段到底存什么
_type 不是字符串名，也不是 Go 源码里的类型字面量，而是运行时生成的、指向类型元数据的指针。它描述的是“这个值在内存里怎么布局”。
例如：
-
var x interface{} = 42→_type指向runtime._type中代表int的实例，含size=8、kind=2（kindInt）、hash=0xabc123等； -
var y interface{} = struct{A int}{1}→_type指向一个匿名结构体专属的元数据，含字段偏移、对齐等信息； -
var z interface{} = nil→_type == nil，此时eface处于未初始化状态，z == nil为 true，但不能对其做任何类型操作。
注意：_type 一旦确定就不会变——哪怕你把 int 赋给 interface{} 再转成 string，中间也必须经过显式类型转换，_type 不会自动更新。
容易被忽略的 eface 值拷贝陷阱
eface 是值类型，每次传参或赋值都复制两个指针。表面看是“传引用”，实则只是复制了指针，不是复制背后的数据。
典型问题场景：
- 函数接收
interface{}参数并修改其内部字段（如struct成员），原变量不受影响——因为data指向的是副本地址； - 把大结构体（如含 megabyte 级 slice 的 struct）直接赋给
interface{}，会触发一次内存拷贝（取决于逃逸分析），而非共享； - 用
sync.Pool存interface{}时，如果池中对象曾存过某struct，下次取出后_type仍指向旧类型，若误用会导致 panic 或静默错误。
真正需要零拷贝共享时，应显式传指针：interface{} 存 *MyStruct，而不是 MyStruct。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
