Go接口方法调用通过itab查函数指针数组实现间接跳转与receiver重绑定：非空接口（如io.Reader）用iface结构（含tab*itab和data），空接口（interface{}）用eface（仅_type和data），itab为“接口类型+具体类型”二元映射，含inter、_type、hash、fun数组，懒构建且不可跨接口复用。
Go 接口方法调用不是查 vtable，而是通过 itab 查函数指针数组，每次调用都是一次间接跳转 + receiver 重绑定。
接口值底层到底是 iface 还是 eface
取决于接口有没有方法：有方法（如 io.Reader）用 iface；没方法（interface{} 或 any）用 eface。两者都含 data 字段指向实际数据，但 iface 多一个 tab *itab，而 eface 只存 _type。这意味着空接口不能做方法调用——它压根没地方存方法地址。
常见错误现象：var x interface{} = &MyStruct{}; x.Read(buf) 编译直接报错 x.Read undefined，不是运行时 panic，因为语法上就不合法。
使用场景：当你看到函数参数是 interface{}，它只用于泛型前的类型擦除或反射入口；一旦要调方法，就必须是带方法签名的非空接口。
itab 是什么，为什么每次赋值都可能触发构建
itab 是接口动态派发的核心缓存结构，本质是「接口类型」和「具体类型」的二元映射。它包含：inter（接口类型指针）、_type（具体类型指针）、hash（类型哈希，用于快速断言）、fun（函数指针数组）。
itab 是懒生成的：第一次把 *os.File 赋给 io.Reader 时才构建，之后复用。但注意：两个不同接口（哪怕方法签名完全一样）会生成各自独立的 itab，无法共享。
容易踩的坑：func (t T) M() 和 func (t *T) M() 是两个完全不同的方法集。若接口要求指针接收者方法，你传入值类型变量（T{}），编译器直接拒绝，不会生成 itab；反之亦然。这不是运行时问题，是编译期契约检查。
动态派发的实际调用过程
当你写 r.Read(buf)（其中 r 是 io.Reader 类型），底层执行三步：
- 从
r的iface中取出tab指针 - 查
tab.fun[0]（Read是io.Reader第一个方法）拿到函数地址 - 把
r.data当作 receiver，调用该地址对应函数
这个过程无法被编译器内联，哪怕 (*os.File).Read 只有一行 return syscall.Read(...)。性能影响在热点路径（如每秒百万次 Write）中可被 pprof 定位到 runtime.ifaceE2I 或 runtime.interfacelookup 占比上升。
参数差异：data 存的是 receiver 的地址，所以值类型会被拷贝一份再取地址；指针类型则直接存原指针。这也是为什么大结构体建议用指针接收者——避免无谓拷贝，且不影响接口赋值逻辑。
为什么反射不能替代接口做多态
reflect.Value.Call 和接口方法调用走的是两条完全不同的路径：前者在运行时解析类型、包装参数、检查可调用性、分配临时栈帧；后者只是查表跳转。前者慢一个数量级不止，且不参与类型系统调度。
常见错误现象：reflect.Value.MethodByName("M").Call(...) 找不到方法，往往是因为结构体实现了 M，但没实现某接口，而反射并不关心接口契约——它只看结构体自身定义的方法。更隐蔽的是：若方法是 func (t *T) M()，你对 reflect.ValueOf(T{}) 调用会失败，因为非指针值不可寻址；而接口方式下，编译器早就在赋值时拦住了你。
真正需要抽象时，优先组合接口，而不是在运行时靠反射“硬凑”。itab 的存在本身就是为了让你在类型安全前提下获得动态行为，绕开它等于放弃 Go 的设计哲学。
复杂点在于：itab 的匹配发生在赋值那一刻，不是调用那一刻；而它的哈希、方法地址填充、跨包类型一致性，全由运行时静默管理——你看不见它，但它决定了你的代码能不能跑、跑得多快、出错时提示是否友好。
