interface{}底层是eface结构，仅含_type和data两个指针，无方法表、不参与动态分派，纯类型擦除与值搬运；赋值只拷贝16字节，但断言失败会panic，且nil判断需同时满足_type和data为nil。
空接口 interface{} 底层是 eface，不是泛型容器
它只是两个指针：_type 指向运行时类型元数据，data 指向值本身。没有方法表、不参与动态分派，纯类型擦除+值搬运。
常见错误是以为 interface{} 能“自动适配方法调用”——它不能。一旦你把一个 *File 赋给 interface{}，再想调用 Write() 就必须先断言回原类型：v.(*File).Write(...)，否则编译失败。
- 赋值开销小：只拷贝两个机器字（64 位下共 16 字节）
- 类型断言失败会 panic，不是 nil 判断就能绕过
-
fmt.Printf("%v", x)这类通用打印依赖eface，但内部仍要靠_type.String()或反射 fallback
带方法的接口底层是 iface，核心在 itab
iface 的 tab 字段指向 itab 结构，它不是编译期常量，而是在首次赋值时由 runtime 动态生成并缓存的。里面存了接口类型、具体类型、哈希值，以及最关键的方法指针数组 fun[1]uintptr。
容易踩的坑：方法地址写死在 itab.fun 里，所以接口调用不是虚函数表查找，而是直接跳转——这带来性能优势，但也意味着：如果接口方法签名变更（比如加参数），旧 itab 缓存不会自动失效，会导致 panic 或未定义行为。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
- 实现同一接口的不同类型，各自有独立
itab实例 - 同一个类型实现多个接口，会生成多个
itab（不共享） - 方法调用本质是
itab.fun[i](data, args...)，data是原始值地址，不是接口变量地址
为什么 nil 接口变量不等于 nil 值
因为 iface 是双字段结构：tab == nil 且 data == nil 才算真正 nil；而常见误判是只检查 data ——比如 var w io.Writer = (*os.File)(nil)，此时 tab 非 nil（已绑定 *os.File 和 io.Writer 的 itab），data 是 nil，整个接口变量非 nil，但调用 w.Write() 会 panic。
- 判断接口是否可安全调用，不能只用
w == nil，得结合具体场景看是否可能含 nil 指针 - 返回接口的函数，若内部构造了非 nil
tab+ nildata，调用方需主动防御 - 空接口
interface{}没这个问题：它的_type为 nil 时，整个eface才是 nil
接口转换不触发内存拷贝，但影响逃逸分析
把局部变量 file 赋给接口，data 字段存的是该变量地址。如果 file 是栈上对象，这次赋值可能迫使它逃逸到堆——不是因为接口本身堆分配，而是编译器判定其生命周期超出当前栈帧。
这个细节常被忽略：接口变量本身小（16 字节），但背后引用的数据可能很大，且生命周期由接口变量控制。比如传入 channel 的接口值，接收方持有它时，原始数据就不能回收。
- 大结构体直接转接口，比转指针更易触发逃逸
- benchmark 中接口调用的“慢”，往往不是动态分派开销，而是间接访问引发的 cache miss
- go tool compile -gcflags="-m" 可查看具体逃逸决策
itab 的生成时机和 eface 的零抽象成本之间。真正难调试的，永远是那个 tab != nil && data == nil 的中间态。 
