go接口调用无法内联，因需动态查itab获取函数指针并重绑定receiver；空接口无方法表，不能调用方法；接收者类型不匹配时编译失败，非运行时错误。
Go 接口调用不是虚函数表跳转，而是每次都要通过 itab 查函数指针数组 + 重绑定 receiver —— 这个过程无法内联，性能敏感路径必须实测。
为什么 r.Read() 不能被编译器内联
Go 编译器在遇到接口方法调用时，无法在编译期确定具体目标函数地址。它只能生成间接跳转代码：先从 r 的 iface 中取出 tab，再查 tab.fun[0]（Read 是 io.Reader 第一个方法），最后把 r.data 当作 receiver 调用。这个三步链路打断了所有内联机会。
常见错误现象：pprof 显示 runtime.ifaceE2I 或 runtime.interfacelookup 占比异常高，尤其在高频 I/O 循环中；汇编里能看到 CALL 指令目标是寄存器而非固定地址。
- 值接收者方法和指针接收者方法会生成完全不同的
itab，哪怕签名一致也无法复用 -
itab构建是懒加载的，首次赋值才触发，但后续复用不跨接口——io.Reader和另一个签名相同的自定义接口会各自构建一套 - 大结构体用值接收者实现接口时，
data字段存的是该结构体的拷贝地址，额外开销隐含在接口赋值那一刻
interface{} 和 io.Reader 的底层结构完全不同
空接口 interface{} 对应 eface 结构，只含 _type 和 data；非空接口如 io.Reader 对应 iface，多一个 tab *itab 字段。这意味着：
常见错误现象：var x interface{} = &MyStruct{}; x.Read(buf) 直接编译失败，报错 x.Read undefined —— 不是运行时 panic，是语法层面不合法，因为 eface 根本没地方存方法地址。
- 函数参数写成
func f(v interface{})，仅用于类型擦除或反射入口；要调方法，必须声明为带方法签名的非空接口 -
eface的_type可用于reflect.TypeOf()，但无法做任何方法调度 - 把指针赋给空接口，
data存的就是原指针；把值赋给空接口，data指向的是该值的一份拷贝
接收者类型不匹配时，根本不会走到 itab 构建阶段
接口要求 func (t *T) M()，你传 T{}（值类型变量），Go 编译器直接拒绝，连 itab 都不会尝试构建。这不是运行时类型检查失败，是编译期契约验证未通过。
使用场景：当你看到 cannot use T literal (type T) as type Interface in assignment: T does not implement Interface (M method has pointer receiver) 这类错误，说明结构体方法集和接口契约不匹配。
- 值类型
T实现的方法集 = 所有值接收者方法 - 指针类型
*T实现的方法集 = 值接收者 + 指针接收者方法 - 因此
*T能赋给要求指针接收者方法的接口，T不能，除非接口方法全为值接收者
真正容易被忽略的是：接口赋值那一刻的拷贝成本和 itab 构建时机。前者影响内存，后者影响首次调用延迟；而绝大多数人只盯着方法调用本身，却忘了前面两步才是真实开销所在。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
