类型转换在编译期完成、零运行时开销；类型断言是运行时操作，成功或失败均约10–30纳秒，panic形式达微秒级，高频误用会累积开销并暴露抽象泄漏。
类型转换（Type Conversion）在编译期完成，几乎零开销；类型断言（Type Assertion）是运行时操作，有实际检查成本，但现代 Go 运行时已高度优化，单次断言开销极小（通常几十纳秒），不过仍需警惕高频误用场景。
type conversion 是纯编译期行为，无 runtime 成本
Type Conversion（如 int64(x)、string(b)、rune(i)）不生成任何运行时指令。只要源类型和目标类型满足 Go 规范的可转换条件（例如底层类型一致、数值范围兼容），编译器就在生成机器码时直接完成位/值重解释或零拷贝转换。
- 整数转浮点（
float64(i)）：生成一条cvtsi2sd指令，无函数调用 - 字节切片转字符串（
string(b)）：仅复制头信息（2 个指针 + 1 个 len），不拷贝底层数组数据 - struct 字段类型匹配时直接返回（如
return a.field1），连转换都不需要 —— 这比string(a.field1)还省一层语义
type assertion 的开销取决于接口值状态
x.(T) 在运行时必须做两件事：检查 x 是否为 nil，再检查其底层类型是否等于 T。这个过程涉及对 iface 或 eface 结构体字段的读取与比较，不是纯内联操作。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 成功断言（
x非 nil 且类型匹配）：典型耗时约 10–30 ns（实测于 amd64 Go 1.21+），主要花在类型表查表上 - 失败断言（
ok := false形式）：开销与成功相近，因为类型检查逻辑相同 - panic 形式（
x.(T)单返回值）：除检查外还要构造 panic 对象，开销显著上升（微秒级），应严格避免在热路径使用 - 接口值含指针类型（如
*MyStruct）却断言为值类型（MyStruct）：必然失败，且错误信息明确提示 “not MyStruct”，这类误配会白耗一次检查
高频断言场景下容易被忽略的性能放大点
单次断言很快，但循环中反复对同一接口变量做相同断言，或在 hot path（如 HTTP 中间件、序列化循环）里密集断言，会累积可观开销，并掩盖更深层的设计问题。
立即学习“go语言免费学习笔记（深入）”；
- 不要在 for-range 循环里对每个
interface{}元素重复写v.(string)—— 若已知全部是string，应改用[]string切片，避免接口装箱/拆箱 - 用
switch v := x.(type)替代一连串if v, ok := x.(T1); ok { ... } else if v, ok := x.(T2); ok { ... }，前者由编译器生成跳转表，后者是线性判断 - 结构体字段本身就是具体类型（如
field1 string），写a.field1.(string)不仅非法，还会让开发者误以为“断言有代价所以要省”，其实它根本过不了编译 —— 这类错误反映的是对类型系统理解偏差，而非性能权衡
真正影响性能的往往不是断言本身，而是它所暴露的抽象泄漏：用 interface{} 承载本可静态确定的类型，导致每次访问都要运行时验证。能用具体类型的地方，就别用接口兜底。
