go中类型断言与类型切换性能极佳，单次仅约1.6–1.7纳秒，与直接方法调用基本持平；其本质是编译期已知类型的指针比较，无反射、无堆分配，属常数时间操作。
go 中 interface{} 类型断言本身几乎没有运行时开销，但实际性能影响取决于底层类型是否已知、是否触发反射、以及是否嵌套在高频路径中。
interface{} 断言的底层成本几乎为零
Go 的接口值在内存中是两个字（16 字节）：一个指向类型信息的指针，一个指向数据的指针。类型断言 x.(T) 本质只是比较当前接口值中的类型指针是否与目标类型 T 的类型描述符地址一致 —— 这是一次指针比较，常数时间，无内存分配，不触发反射。
这意味着：只要目标类型 T 是编译期已知的确定类型（如 string、int、*MyStruct），断言就是纯 CPU 比较，快得可以忽略。
- 不涉及 GC 扫描或堆分配
- 不会调用 runtime.convT2X 系列函数（那是接口赋值时才走的路径）
- 汇编层面通常编译为几条 MOV + CMP 指令
什么时候性能会明显变差
真正拖慢的不是断言动作本身，而是断言失败后你写的 fallback 逻辑，或者你误用了需要反射的场景。
- 在循环里对
interface{}做大量断言，且每次断言类型都不固定（比如随机混入string/float64/[]interface{}），CPU 分支预测失败率上升，间接影响吞吐 - 用
reflect.TypeOf(x).Kind()或reflect.ValueOf(x)替代断言 —— 反射开销比断言高 100x 以上，且触发逃逸和堆分配 - 对 JSON 解析后的
map[string]interface{}做深层嵌套断言（如m["data"].([]interface{})[0].(map[string]interface{})["id"].(float64)），虽然每步断言都快，但链式调用叠加了多次类型检查 + 多次接口值解包，可读性差且易出错 - 在 hot path（如 HTTP 中间件、gRPC 拦截器）里对每个请求做 5+ 次不同类型的断言，即使单次快，累积仍可观
type switch 比连续 if-else 断言更高效
当你需要判断一个 interface{} 可能属于多个类型时，用 switch v := x.(type) 而不是一连串 if s, ok := x.(string); ok { ... } else if i, ok := x.(int); ok { ... }。
原因：type switch 在编译期生成跳转表（jump table），只做一次类型比较；而 if 链每次都要重新取接口的类型字段再比对，最坏情况要比较 N 次。
switch v := data.(type) {
case string:
processString(v)
case int, int64:
processNumber(float64(v))
case []interface{}:
processSlice(v)
default:
log.Warn("unknown type")
}
注意：case int, int64 是合法的，且共用一个分支，无需重复写逻辑。
真正要注意的不是“断言慢”，而是“断言掩盖了设计问题”：频繁需要断言，往往说明该处本该用具体类型、泛型约束，或提前做结构化解析。把类型不确定性推到运行时，既损失性能，也增加维护成本。
