类型断言在汇编中仅是两次指针比较，Go编译器对x.(T)生成极简代码：读itab和data字段，用CMPQ比itab与T的类型描述符地址，相等则继续，否则跳fallback，无函数调用、无堆分配、不进runtime。
类型断言在汇编里只是两次指针比较
Go 编译器对 x.(T) 这种编译期已知目标类型的断言，几乎不生成额外逻辑——它只读取接口值的两个字段：itab 指针（类型信息）和 data 指针（值地址），然后拿 itab 和目标类型 T 的全局类型描述符地址做一次 CMPQ 比较。成功就继续用 data，失败就跳转 fallback。没有函数调用、没有堆分配、不进 runtime。
比如 val, ok := i.(string) 在 AMD64 汇编中通常展开为：
MOVQ i+0(FP), AX // 加载 itab 地址 CMPQ AX, type.string(SB) // 直接比对 JEQ ok_label
这跟 if ptr != nil 一样轻量。你看到的“断言开销”，99% 来自后续对 data 的解引用或 fallback 分支里的反射/日志/错误构造。
type switch 为什么比 if 链快
switch v := x.(type) 被编译成跳转表（jump table），整个判断只查一次接口的 itab 字段，然后根据哈希或偏移直接跳到对应 case；而连续写 if s, ok := x.(string); ok { ... } else if i, ok := x.(int); ok { ... }，每次都要重新加载 itab、再比对、再跳转，最坏情况要执行 N 次内存读 + N 次比较。
实际影响明显的场景：
- HTTP 中间件里对每个请求做 5+ 次不同类型的断言
- 解析
map[string]interface{}后嵌套取值，如m["items"].([]interface{})[0].(map[string]interface{})["id"].(float64) - 高频循环中混入多种类型（
string/int/[]byte随机交替）导致 CPU 分支预测失败率上升
什么时候会触发反射、逃逸或 conv 函数
真正的性能拐点不是断言本身，而是你让它“干了不该干的事”：
- 用
reflect.TypeOf(x)或reflect.ValueOf(x)替代断言 —— 反射路径要查类型系统、构造reflect.Type对象、可能逃逸到堆，开销是断言的 100 倍以上 - 断言目标是接口类型（如
x.(io.Reader)）且右侧值未实现该接口全部方法 —— 此时需查itab表是否已缓存匹配项，未命中会触发 runtime.getitab，但仍是纯 CPU 查表，无 GC 影响 - 把断言写在闭包里又捕获了大对象 —— 不是断言慢，是闭包逃逸让整个栈帧升堆
空接口赋值和断言共用同一块内存布局
interface{}（即 eface）在内存中固定是两个 uintptr：_type 指针 + data 指针。赋值如 var i interface{} = "hello"，只是把 type.string(SB) 和字符串底层数组地址分别填进这两个字段；断言 i.(string) 就是再把第一个字段拿出来跟 type.string(SB) 对一遍。它们共享同一份底层结构，不存在“转换拷贝”。
这也是为什么你可以用 unsafe.Pointer 直接从 interface{} 里取出 data 字段（虽然不推荐）——因为结构稳定、无隐藏字段、无 padding。
真正容易被忽略的点：断言快的前提是目标类型 T 必须是编译期常量。如果通过变量传入类型（比如想泛化断言逻辑），那就只能走 reflect，性能断崖下跌。
