go接口转换非类型擦除，而是依目标接口是否含方法选择eface或iface路径：interface{}赋值给带方法接口时触发iface构造，需查表生成itab，若类型未实现全部方法则panic；_type指针全局唯一，但eface与iface中访问方式不同。
Go 接口转换不是“类型擦除后重装”，而是根据目标接口是否含方法，决定走 eface 还是 iface 的内存构造路径——错配结构会导致 panic 或静默行为异常。
为什么 interface{} 赋值给带方法的接口会触发 iface 构造
空接口 interface{} 底层是 eface，只存 _type 和 data；但一旦赋值给如 fmt.Stringer 这类含方法的接口，运行时必须构建完整的 iface，其中关键一步是查表生成或复用对应的 itab。
这个过程不是简单指针拷贝：若具体类型未实现该接口所有方法，itab 查表失败，赋值语句直接 panic（错误信息类似 panic: interface conversion: xxx is not fmt.Stringer: missing method String）。
- 只有编译期能确认方法集满足时，才会在运行时安全填充
itab.fun数组 - 同一个
(T, I)组合（T 是具体类型，I 是接口）的itab全局唯一，首次构造后缓存于runtime.itabTable - 若 T 是指针类型（如
*MyStruct），而接口方法集由*MyStruct实现，但你传的是MyStruct{}值，则查表失败——这是最常被忽略的“方法接收者不匹配”问题
eface 到 iface 转换时，_type 和 itab._type 是同一个指针吗
是。无论走 eface 还是 iface，底层指向具体值类型的 _type 元数据地址完全一致——它来自 Go 运行时对每个类型的唯一描述实例，比如所有 int 值共享同一个 runtime._type 地址。
区别在于：
eface._type 直接暴露给用户（例如通过 reflect.TypeOf(x).Kind() 获取）；
iface.tab._type 被封装在 itab 内部，仅用于运行时方法派发和类型断言校验。
- 不要试图通过 unsafe 比较两个
_type指针来判断“类型相等”——应使用reflect.TypeOf(a).AssignableTo(reflect.TypeOf(b)) - 当值为 nil 指针（如
var p *MyStruct）赋给接口时，data为 nil，但_type仍有效；此时若调用方法，会 panic：nil pointer dereference - 空接口转非空接口时，不会复制数据，只复用原
data指针——所以修改底层值会影响所有持有该接口的变量
类型断言失败时，eface 和 iface 的行为差异
语法都是 v, ok := x.(T)，但底层检查逻辑不同：
对 eface（即 interface{}）：只需比对 eface._type == target._type，O(1) 时间；
对 iface（如 io.Reader）：需先定位其 itab，再检查 itab.inter（接口定义）与目标类型是否兼容，涉及哈希查找 + 方法签名比对，略慢但仍是常数时间。
- 断言
nil接口（var r io.Reader）为具体类型，结果恒为(nil, false)，因为iface.tab == nil - 断言一个
iface为另一个不相关接口（如r.(fmt.Stringer)），即使底层值类型同时实现了两者，也必须存在对应itab；若从未发生过该转换，运行时会现场构造——这步可能失败（如方法签名不匹配） - 避免在热循环中频繁做跨接口断言，优先设计为单次转换 + 多次使用
真正容易出问题的地方不在结构本身，而在“值为 nil 时的 data 指针”和“方法接收者类型是否与接口要求一致”——这两点不靠调试器看 eface/iface 内存布局很难直观发现，必须结合 panic 信息和方法集定义反推。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
