itab查找使用哈希表，key为interfacetype与_type指针异或取模；不同包中签名相同的接口因指针不同无法共享itab；getitab运行时检查实现并插入，失败panic极少发生；构建时加全局锁itabLock，查找无锁；空接口eface不走itabTable。
itab 查找走的是哈希表，但 key 不是字符串
go 运行时维护的全局 itabtable 是一个哈希表，但它不拿接口名或类型名拼接成字符串当 key。真正的 key 是由 interfacetype* 和 _type* 两个指针值异或再取模算出来的——本质上是把两个内存地址“混合”后映射到桶数组索引。这意味着：即使两个接口方法签名完全一样（比如都只有 read(p []byte) (n int, err error)），只要它们是不同包里定义的 io.reader 和自定义的 myreader，就对应不同的 interfacetype 指针，必然落在不同桶里，无法共享 itab。
getitab 函数会懒加载，但失败时 panic 不在运行时发生
getitab 是实际触发查找和构建 itab 的核心函数。它先查哈希表，命中就直接返回；没命中则做两件事：检查具体类型是否真实现了该接口（比对方法集），若通过就分配新 itab 并插入表中。注意这个检查发生在运行时，但「类型未实现接口」的错误绝大多数会在编译期报出，比如 cannot use … as … value in assignment: … does not implement …。只有极少数情况（如通过反射或 unsafe 绕过编译检查）才会让 getitab 在运行时 panic。
并发安全靠原子操作 + 全局锁，不是无锁哈希
多个 goroutine 同时首次把 *os.File 赋给 io.Reader 时，可能同时触发 getitab 查不到 itab 的分支。Go 不靠 CAS 循环重试，而是在哈希表插入前加了全局 itabLock。也就是说：itab 构建阶段有锁，但后续所有查找都是无锁的纯哈希读取。这导致第一次接口赋值有轻微竞争开销，但之后复用完全零成本。你不需要、也不应该手动预热 itab，runtime 自己会处理。
空接口 interface{} 不走 itab 表，而是 eface 哈希
别混淆 iface 和 eface。带方法的接口（如 io.Reader）用 iface 结构，依赖 itabTable；而 interface{} 或 any 是 eface，它的类型缓存逻辑独立，查的是另一个叫 efaceHash 的结构，内部只存 _type* 和数据指针，没有方法指针数组。所以给 interface{} 赋值不会触发 getitab，也不会生成 itab —— 这也是为什么空接口转换开销略低于非空接口。
itab 缓存看似透明，但真正容易被忽略的是：它按「接口类型 + 具体类型」二元组合粒度缓存，不是按方法签名；且构建过程虽懒，却牵扯全局锁和类型检查逻辑，不能当成纯查表操作来推理性能。
