itab是非空接口iface中指向接口与具体类型适配信息的指针，存储方法地址及类型元数据；data是指向具体值副本或原指针的unsafe.pointer。
itab 和 data 不是独立存在的结构体字段，而是 Go 接口值（iface/eface）内部的两个核心指针成员，共同构成接口的运行时表示——理解它们的关键在于“谁存类型信息、谁存数据地址、谁管方法跳转”。
itab 是什么？它为什么必须存在
itab（interface table）只出现在非空接口（iface）中，是实现动态方法调用的枢纽。它不是编译期生成的静态表，而是在运行时首次将某具体类型赋给某接口时懒加载生成并缓存的。
-
itab.inter指向接口类型元数据（比如io.Reader的定义），描述“这个接口要哪些方法” -
itab._type指向具体类型的元数据（比如*os.File），描述“这个值是什么类型” -
itab.fun是一个可变长数组，按接口方法声明顺序存放对应的具体函数地址；调用r.Read(buf)时，实际就是从这里取第 0 个地址跳过去执行 - 如果类型没实现接口所有方法，
itab.fun[0]会被设为 0，后续调用直接 panic “method not implemented”
data 指针指向哪里？值类型和指针类型行为不同
data 字段始终是 unsafe.Pointer，但它所指的内容取决于你赋给接口的是值还是指针：
- 赋值的是值类型（如
struct{}实例），data指向该值的一份**栈/堆上拷贝**（注意：不是原变量地址） - 赋值的是指针类型（如
&s），data就直接等于该指针值，即指向原始对象 - 对 map/slice/func 这类引用类型，即使你传的是值（如
m := make(map[string]int); var i interface{} = m），data指向的仍是其底层结构体（含array unsafe.Pointer等字段）的副本——所以修改副本里的指针字段不会影响原 map，但通过该副本仍能读写原底层数组
空接口 interface{} 为什么没有 itab
空接口（eface）不包含任何方法，因此不需要方法分派逻辑，也就不需要 itab 及其维护的函数指针表。它的结构极简：
-
_type字段直接存具体类型的元数据指针（等价于itab._type） -
data行为与iface.data完全一致：值类型→拷贝地址，指针类型→原指针值 - 正因为没 itab，
interface{}赋值开销略小，但做类型断言（v.(T)）或反射时仍需查_type，性能差异微乎其微
常见 panic 场景：itab 匹配失败的真实原因
这类 panic 往往发生在接口赋值瞬间，而非调用时，本质是编译器发现“值接收者方法 + 指针实例”或“指针接收者方法 + 值实例”的组合不满足方法集规则：
- 你写了
func (t T) M()（值接收者），却试图把&t赋给接口：可以，因为&t的方法集包含所有T的方法 - 你写了
func (t *T) M()（指针接收者），却试图把t赋给接口：编译报错，t的方法集不包含(*T).M - 第三方库文档里只写
func (t T) Write(...)，你传了&buf却发现 panic —— 实际上是它内部用了指针接收者，但文档漏标了*
真正容易被忽略的是：itab 在首次赋值时就已确定，之后无论你怎么转型、断言，只要底层类型没变，itab 就复用；但一旦你用类型转换绕过编译检查（比如 unsafe 强转），运行时 itab 校验失败会立刻 panic，而不是延迟到方法调用。
