nil接口不等于nil指针，因其底层是两字宽结构体，需tab和data同时为零才为nil；非空指针赋值后tab非零，接口即非nil，调用方法会panic。
为什么 nil 接口不等于 nil 指针？
因为 Go 的接口变量本质是两字宽结构体（64 位下 16 字节），必须 tab（或 _type）和 data 同时为零，才真正是 nil。只要装了一个非空指针（哪怕它自己是 nil），tab 或 _type 就已非零，整个接口就非 nil。
-
var r io.Reader→r == nil成立（tab == nil && data == nil） -
var b *bytes.Buffer; r = b→r == nil不成立（tab != nil，但data == nil） - 此时调用
r.Read()会 panic：invalid memory address or nil pointer dereference
怎么用 unsafe 和 reflect 窥探 iface 或 eface？
不能直接声明或访问 iface/eface，但可通过反射获取其内存头地址，再用 unsafe 偏移读取字段——仅限调试、序列化库等极少数场景，生产代码中应避免。
-
reflect.ValueOf(x).UnsafeAddr()得到接口头起始地址 - 64 位系统下：
offset 0是tab（iface）或_type（eface），offset 8是data - 示例：判断一个
interface{}是否装了nil *T：if reflect.ValueOf(i).Kind() == reflect.Ptr && reflect.ValueOf(i).IsNil()
interface{} 和具体接口（如 io.Reader）的底层区别在哪？
核心差异在是否需要方法表：interface{} 用 eface（只有 _type + data），而 io.Reader 这类带方法的接口用 iface（含 itab + data）。
-
itab是编译期生成的只读结构，全局唯一，存于.rodata段，不参与 GC -
itab.fun是函数指针数组，调用接口方法时靠它跳转，有轻微间接调用开销 - 无论底层类型多大（比如一个 1MB 的 struct），接口变量大小恒为 16 字节（64 位）
什么时候真得关心 itab 和 data 的内存布局？
99% 的业务代码完全不需要。只有三类情况值得介入：
立即学习“go语言免费学习笔记（深入）”；
- 写高性能序列化/反序列化逻辑，想绕过反射直接提取
data地址做零拷贝 - GC 调试时发现某接口长期持有一个已释放的大对象——可能是
itab还活着导致 GC 误判引用 - cgo 场景下需手动构造
iface传给 C（极度危险，几乎总是有更安全替代方案）
别为了“理解原理”去硬改或依赖这些内部结构；Go 把接口抽象得足够干净，iface 和 eface 是运行时服务机制，不是给你日常编码用的。真正容易被忽略的是：itab 的哈希值用于快速类型断言，但它一旦生成就不会变——所以泛型普及后，很多旧式接口模式正在被更明确的类型约束替代。
