接口断言v.(T)几乎无开销，因是编译器内联指令，仅比较指针；慢的是reflect.ValueOf(v).Interface().(T)，它引发两次装箱逃逸和堆分配，实测慢100倍以上。
接口断言比反射快 5–10 倍，且不逃逸、不查表、无函数调用；真正拖慢性能的不是断言本身，而是你把它和 reflect.ValueOf 混在一起用了。
为什么 v.(T) 几乎没开销
Go 的类型断言 v.(T) 是编译器生成的内联指令，运行时只做两件事：
- 检查
v的数据指针是否为nil - 比较接口头里存的类型指针（
itab或_type）是否等于目标类型T在全局类型表中的地址
整个过程不分配内存、不触发 GC、不走反射路径。实测 1000 万次 v.(string) 平均耗时仅 1.68 ns/op，和直接调用 len(s) 基本持平。
常见误解来源：
- 把
reflect.Value.Convert当成类型断言——它真要查runtime.types表、校验底层兼容性、复制内存 - 在
map[interface{}]interface{}中反复断言同一 value——瓶颈是 map 查找 + 接口装箱，不是断言 - 写
s.field.(string)这种语法——编译直接报错，根本进不了运行时
reflect.ValueOf(v).Interface().(T) 为什么慢两个数量级
这行代码实际做了三件事：
- 先将
v装箱进reflect.Value（逃逸到堆，拷贝值） - 再调用
.Interface()拆出来（又一次接口装箱） - 最后才做
.(T)断言（前面两步白干了）
相当于“把书塞进箱子 → 拿出箱子 → 打开箱子 → 取出书”，而纯断言是“直接伸手拿书”。实测这种写法比纯 v.(T) 慢 100 倍以上，尤其对小结构体或高频调用路径，分配压力远大于断言本身。
典型误用场景：
-
func handle(i interface{}) { v := reflect.ValueOf(i); if v.Kind() == reflect.String { s := v.String(); ... } }——完全可以用s, ok := i.(string)替代 - 在 HTTP 中间件里对
ctx.Value("user")先reflect.ValueOf再断言——应直接安全断言
什么时候该用断言，什么时候必须用反射
断言适用所有已知类型集合的场景：
- 从
context.Context取值（如ctx.Value("req").(*http.Request)） - 处理
map[string]interface{}解析后的字段（如data["id"].(float64)） -
type switch分支处理有限几种类型（int/string/bool）
反射只在以下情况不可替代：
- 类型完全未知，且需动态读写字段（如通用 JSON patch、ORM 字段映射）
- 需要遍历方法集或检查
Implements() - 构建泛型容器（如
sync.Map底层对 key/value 的类型擦除）
注意：reflect.TypeOf 和 reflect.ValueOf 本身不慢，慢的是后续的 .Call()、.Set()、.Interface() 等操作。如果只是取类型名或判断 Kind()，开销可控；一旦涉及值操作，就要警惕。
最容易被忽略的性能陷阱：装箱成本远高于断言
断言快，但让值进入接口的过程（即“装箱”）可能很重：
- 把一个
struct{ ID int; Name string }（24 字节）塞进interface{}，会拷贝到堆上 - 高频调用中反复装箱 + 断言，GC 压力来自分配，不是断言逻辑
-
context.WithValue(ctx, key, smallStruct{})是典型反模式——应传指针或预定义结构体指针
真正该优化的，从来不是 v.(T) 这一行，而是它前面那句 var v interface{} = ...。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
