Go反射中类型断言开销主要在v.Interface()分配接口头并拷贝数据，叠加断言时查runtime类型哈希表，整体比直接访问慢50–100倍；应避免循环内重复调用v.Interface().(T)。
反射中类型断言的开销到底在哪
Go 反射里的类型断言（比如 v.Interface().(MyStruct)）本身不直接触发 panic，但它的性能代价藏在两层转换里：先调用 v.Interface() 把 reflect.Value 拆箱成 interface{}，再对这个接口做断言。每次 Interface() 都要分配新接口头、拷贝底层数据（尤其对大结构体或切片），而断言又得查 runtime 的类型哈希表——这两步加起来比直接变量访问慢 50–100 倍。
避免重复 Interface() + 断言组合
常见写法是反复调用 v.Interface() 然后断言，比如循环里处理字段：
Interface()
- 把
v.Interface()结果存到局部变量，后续所有断言都基于它 - 如果字段类型固定，优先用
v.String()、v.Int()等原生方法，绕过Interface() - 对结构体字段，用
v.Field(i).Addr().Interface()获取指针再断言，避免值拷贝
用 type switch 替代链式断言
当需要匹配多个可能类型时，type switch 比一连串 if _, ok := x.(T1); ok { ... } else if _, ok := x.(T2); ok { ... } 快得多——它只查一次类型表，且编译器能优化跳转逻辑。
注意两个坑：
-
type switch的变量必须是interface{}，不能直接对reflect.Value用 - 别在
type switch里嵌套反射操作；先完成断言拿到具体类型值，再用反射处理子字段 - 如果只有 2–3 种类型，且其中一种占 90% 以上，单次断言 +
ok判断反而比type switch更快（分支预测友好）
缓存 Type 和 Value 的边界在哪
缓存 reflect.Type 几乎总值得做，因为 reflect.TypeOf(x) 每次都要解析 abi.Type 并构造新接口；但缓存 reflect.Value 要小心——它包含指向原始数据的指针，如果原始变量生命周期结束（比如函数返回后），缓存的 Value 就会变成悬垂引用，导致不可预测行为。
更安全的做法是：
- 全局缓存
reflect.Type，例如var myStructType = reflect.TypeOf(MyStruct{}) - 对高频访问的结构体字段，缓存
StructField切片（t.FieldByName("xxx")的结果），而不是Value - 永远不要跨 goroutine 缓存
reflect.Value，除非你 100% 控制其底层数据生命周期
真正难优化的从来不是单次反射，而是反射和类型断言混在一起、又没控制好生命周期的组合——这时候看 profile 往往发现 runtime.convT2I 和 runtime.ifaceE2I 占 CPU 最高，而不是 reflect.Value.Method。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
