interface{} 不走 itab 查表，因其底层为 eface 结构，仅含 _type 和 data 字段，无 tab *itab，故不存方法、无法调用方法，所有操作（如断言、反射）均基于 _type 校验而非动态派发。
interface{} 没有动态分派 —— 它压根不存方法，也根本不会调用任何方法。 所有对 interface{} 的“调用”行为（比如断言、反射、fmt.printf）都发生在运行时查 _type 和解包 data 之后，和接口的动态方法派发机制（即 itab 查表）完全无关。
为什么 interface{} 不走 itab 查表
interface{} 对应底层结构 eface，只含两个字段：_type（指向类型元信息）和 data（指向值数据）。它没有 tab *itab 字段，因此不存在方法表、不参与任何方法匹配或函数指针跳转。
- 你不能对
interface{}变量直接调用方法，编译器会报错：无法在interface{}上调用方法 - 所谓“动态行为”，比如
v.(string)或reflect.ValueOf(v)，本质是 runtime 根据_type的哈希和布局做类型校验，不是派发 - 如果
data == nil但_type != nil（如未初始化的*os.File赋给interface{}），断言成功但后续解引用仍 panic
interface{} 断言失败的真实原因
断言 v.(T) 失败不是因为“找不到方法”，而是 runtime 对比了当前 eface._type 和目标类型 T 的 _type 地址或哈希值，二者不等就失败。
- 跨包未导出类型看似同名，实为不同
_type，断言必失败（例如pkg1.Error和pkg2.Error） - 指针与非指针类型是完全不同的
_type：*int≠int，即使底层都存整数 - struct 字段顺序/标签/对齐差异也会导致
_type.hash不同，断言静默失败
什么时候会误以为 interface{} 在“动态分派”
常见于日志、序列化、泛型替代场景，你以为它在“自动适配”，其实只是 fmt 或 json.Marshal 内部做了大量 switch _type.kind 分支判断，或递归调用 reflect.Value.MethodByName —— 这些全是显式控制流，不是 iface 那套 tab.fun[0] 直接跳转。
-
fmt.Printf("%v", x)：内部调用pp.printValue(reflect.ValueOf(x))，靠反射遍历字段，不是接口派发 -
json.Marshal(x)：对interface{}做类型分类（map/slice/struct/nil…），每种走不同编码路径 - 把
map[string]interface{}当“动态对象”用？修改原 map 会导致interface{}中的 slice/map 数据指针失效（因副本地址不变，但底层数组可能被 GC 或 realloc）
真正容易被忽略的是：所有对 interface{} 的操作都绕不开 _type 的一致性。一旦涉及跨模块传递、序列化还原、或反射修改，必须确保类型定义完全一致 —— 否则你看到的不是“动态适配失败”，而是“类型校验静默不匹配”。
