itab 一旦写入全局 itabtable 就永久存在，直到进程退出；它按“接口类型指针 + 具体类型指针”二元组合构建，懒加载、不更新、不回收，键为两指针异或值，跨包同签名接口亦不共享。
itab 不会“失效”，也不会被“重建”——它一旦写入全局 itabtable 就永久存在，直到进程退出。 你遇到的所谓“缓存失效”，其实是没理解 itab 的生成时机和唯一性约束：它按「接口类型指针 + 具体类型指针」二元组合构建，不基于方法签名、不随代码变更刷新、也不因 gc 回收。
为什么修改接口定义后旧 itab 仍能用？
itab 是运行时懒加载的静态映射项，构建后永不更新。即使你改了 io.Reader 的方法签名（比如加个 Close()），已存在的 *os.File → io.Reader itab 依然有效——因为它的 inter 指针仍指向旧的 interfacetype 结构，而该结构在当前二进制中内存布局未变。
- 编译器不会重写已生成的 itab；它只在首次赋值时调用
getitab构建新项 - 若你新增一个接口
MyReader（签名和旧io.Reader完全一致），它仍会生成独立 itab，因为MyReader的inter指针与io.Reader不同 - 修改包内接口定义后，必须重新编译所有引用该接口的代码，否则可能出现
undefined: io.Reader.Read等链接期错误，而非 itab 失效
什么情况下会触发新的 itab 构建？
只有当某个「接口类型 + 具体类型」组合第一次出现在运行时赋值语句中时，getitab 才会执行构建逻辑。常见触发点：
-
var r io.Reader = &bytes.Buffer{}—— 首次将*bytes.Buffer赋给io.Reader -
func f(i io.Reader) {}被调用，且传入此前未见过的具体类型（如自定义*MyReaderImpl） - 通过反射调用
reflect.Value.Convert转成某接口类型，且该组合未缓存
注意：interface{} 赋值不触发 itab 构建，它走的是 eface 路径，查的是另一个哈希表 efaceHash。
并发场景下 itab 构建是否安全？
多个 goroutine 同时首次触发同一 itab 构建时，会竞争全局锁 itabLock，而非无锁重试：
- 锁粒度是整个 itabTable 插入操作，不是 per-itab；这意味着不同接口类型的构建也会相互阻塞
- 构建失败（如类型未实现接口）极少发生，因为编译期已拦截绝大多数情况；运行时 panic 仅出现在反射或
unsafe绕过检查时 - 构建完成后，后续所有查找都是纯哈希读取，无锁、零开销；你不需要、也不应该手动预热 itab
真正容易被忽略的是：itab 缓存的键不是方法签名，而是两个指针值的异或结果；哪怕两个接口在源码里长得一模一样，只要定义在不同包，就完全无法共享。这不是 bug，是 Go 类型系统的有意设计——它把“类型等价性”严格锚定在编译单元和运行时地址上，而不是语义上。
