go接口底层分为eface（空接口）和iface（非空接口）：eface含_type和data两字段，仅存类型与值；iface多出tab*itab，含接口类型、具体类型及方法指针数组，支持动态分派。
Go接口的底层实现不是靠“学概念”记住的，而是靠观察赋值行为、类型断言失败、反射结果这三类现象反推出来的。你不需要读runtime源码也能摸清iface和eface的区别，关键是在写代码时多问一句：“这个接口变量里到底存了什么？”
为什么var w io.Writer = os.File{}会编译失败
因为os.File只实现了*os.File上的方法，而os.File{}是值类型，无法调用指针接收器方法。接口赋值时编译器会检查具体类型是否满足方法集——不是看“有没有实现”，而是看“当前值能否调用那些方法”。
-
os.File{}的方法集为空（它没有定义任何方法） -
&os.File{}的方法集包含Read、Write等，所以能赋给io.Writer - 这个检查发生在编译期，不依赖运行时，但直接影响
reflect.Type.Implements的返回值
interface{} 和 io.Reader 在内存里长得不一样
空接口 interface{} 对应 eface 结构，只有两个字段：_type 和 data；而非空接口如 io.Reader 对应 iface，多了一层 tab *itab，里面存着方法地址数组。
- 传
int(42)给fmt.Println时，实际构造的是eface{ _type: &intType, data: &42 } - 传
&bytes.Buffer{}给io.ReadCloser时，构造的是iface{ tab: &itabForBufferAndReadCloser, data: unsafe.Pointer(&buf) } - 这意味着：空接口开销小，非空接口多了方法表查找成本，但换来的是动态分派能力
类型断言失败时，err 不是 nil 但 v 是零值
比如 v, ok := x.(string)，当 x 是 int 类型的 interface{} 时，ok 为 false，v 是 ""（string 零值），这不是 bug，而是 eface 解包逻辑决定的：它先按目标类型读 data 指针，再校验 _type 是否匹配。
- 如果类型不匹配，
v直接取目标类型的零值，不 panic - 如果用
v := x.(string)（不带ok），才会 panic，因为 runtime 调用ifaceE2I或efaceE2I时发现类型不匹配就触发panic - 这个差异暴露了底层结构：空接口转具体类型走
efaceE2I，非空接口转具体类型走ifaceE2I
真正卡住人的从来不是 iface 和 eface 的字段名，而是当你把一个值类型赋给带指针接收器方法的接口时，编译器沉默地拒绝，或者当你用 reflect.ValueOf(x).Interface() 再转回接口时，发现方法表丢了——这些时刻，才是你该打开 runtime/runtime2.go 查 itab 初始化逻辑的时候。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
