类型断言 value.(t) 是唯一安全获取原始类型的途径，convert 仅支持底层类型兼容的位级转换，二者解决不同问题，类型断言零成本且不逃逸，convert 开销大且需缓存优化。
反射转换 Convert 会丢失类型信息，且无法替代类型断言
Go 的 reflect.Value.Convert 只能在底层类型兼容的前提下做“位级”转换（比如 int → int64），它不检查逻辑语义，也不支持接口到具体类型的还原。你不能用它把一个 interface{} 里的 *string 变成 string —— 那不是转换，是解包，得靠 .Interface() 配合类型断言。
-
Convert要求两个类型有相同的底层类型（unsafe.Sizeof相同 + 对齐一致），否则 panic：reflect: cannot convert … to … - 即使成功，返回的仍是
reflect.Value，还得调.Interface()才能拿到真实值，这步本身就有开销 - 常见误用：试图用
v.Convert(reflect.TypeOf("").Type)把任意值转成string—— 这几乎总失败，因为int和string底层类型不同
类型断言 value.(T) 是唯一安全获取原始类型的途径
当你从 interface{} 或空接口字段里取值，必须用类型断言。这是编译器保证的、零成本的运行时检查（只比指针解引用多一次类型比较）。它不涉及反射，也不触发任何转换逻辑。
- 对非接口类型直接断言会编译报错，所以只能用于
interface{}或带方法的接口变量 - 推荐用双变量形式：
s, ok := value.(string)，避免 panic；如果确定类型一定匹配（比如刚用map[string]interface{}取出来的已知字段），单变量也行 - 注意：断言
nil接口会得到ok == false，但断言(*T)(nil)是合法的，结果是nil值而非 panic
性能差异主要来自逃逸和反射开销，不是“谁更快”的问题
别拿 reflect.Value.Convert 和 .(T) 比性能 —— 它们解决的根本不是同一类问题。前者是反射内部的底层类型适配工具，后者是 Go 类型系统的基石操作。真要测，类型断言永远赢，因为它没反射调用栈、不查类型表、不分配中间 reflect.Value。
- 每次调
reflect.ValueOf(x)都可能让x逃逸到堆上，而类型断言完全不触发逃逸 -
Convert内部要查runtime.types表、校验对齐、复制内存，哪怕只是int32→int64也要走完整反射路径 - 实测：100 万次类型断言耗时约 20ms；同等量级的
Convert（含ValueOf）通常超 150ms，且 GC 压力明显上升
真正该关心的是：什么时候不该用反射
如果你正在纠结 Convert 和类型断言哪个快，大概率说明设计上已经绕远了。Go 的接口和类型系统足够表达绝大多数泛型需求，反射应是最后手段。
立即学习“go语言免费学习笔记（深入）”；
- JSON 解析后想转结构体？用
json.Unmarshal直接进 struct，别先转map[string]interface{}再反射折腾 - 需要动态调方法？优先考虑函数变量或策略接口，而不是
reflect.Value.MethodByName - 必须用反射的场景（如 ORM 字段映射、通用 diff 工具），就把
reflect.Type和reflect.Value缓存起来，避免重复reflect.TypeOf
反射里的每一步都带着隐式判断和边界检查，而类型断言只有一条指令。这个差距在热路径上会立刻显现，但更关键的是：它暴露了抽象层级的错位 —— 用反射模拟类型系统，不如让类型系统自己工作。
