接口断言比反射快，绝大多数场景应优先使用断言；所谓“反射更快”是因压测设计错误——reflect.typeof仅提取类型，而u.(type)含完整分支匹配，等价对比下断言快5–10倍；仅字段名运行时确定、遍历任意结构体字段、实现底层序列化三类问题必须用反射。
接口断言比反射快，绝大多数场景下应无条件优先使用断言；所谓“反射判断类型更快”的压测结论，是误读了测试设计——它测的是 reflect.TypeOf 单次调用 vs switch u.(type) 的完整分支匹配开销，而非等价操作。
为什么“反射比断言快”的压测结果不可信
那几组常被引用的基准测试（如 Benchmark1 vs Benchmark2）存在关键逻辑错位：
-
reflect.TypeOf(u)只做类型提取，不涉及值转换或分支逻辑；而u.(type)是类型开关，隐含多次类型比较和控制流跳转 - 真实等价对比应是：
u.(string)vsreflect.ValueOf(u).Kind() == reflect.String，此时断言稳定快 5–10 倍 - 结构体场景下“反射更快”的现象，本质是测试用了
reflect.TypeOf(u).Name()匹配字符串，而断言写了u.(MyStruct)—— 后者触发了编译器对结构体布局的深度校验，额外增加了指针解引用与内存对齐检查
什么时候必须用反射，而不是硬扛性能损失
反射不是“慢一点但能用”，而是“唯一能干这事”。只有以下三类问题无法用断言解决：
- 字段名在运行时才确定：比如 ORM 解析
json:"user_name"tag 后，调用reflect.ValueOf(&obj).Elem().FieldByName("UserName").Set(...) - 需统一处理任意结构体所有字段：如日志脱敏函数要遍历每个
field.Tag.Get("sensitive") == "true"的字段并清空 - 实现底层序列化逻辑：如
encoding/json必须支持嵌套、未知 tag、自定义 marshaler 接口，这些无法在编译期穷举
一旦进入这三类场景，别试图用断言模拟——代码会迅速膨胀成一堆重复的 if v, ok := x.(T1); ok { ... } else if v, ok := x.(T2); ok { ... }，维护成本远超反射的微秒级开销。
reflect.Value.Interface() 和 Convert() 的典型 panic 场景
这两个函数是反射里最常翻车的点，错误往往不报具体字段，只甩一句 reflect: call of reflect.Value.Interface on zero Value 或 reflect: Call of unexported field：
-
Interface()前必须先调用v.IsValid() && v.CanInterface()，否则对 nil 指针、未导出字段、零值reflect.Value都会 panic -
Convert()要求源Value可寻址（即来自reflect.ValueOf(&x)），且目标类型必须与源类型底层兼容（int→int64可，string→[]byte不可） - 别写
v.Interface().(MyStruct)—— 这等于把反射转回接口后又做一次断言，既多余又增加 panic 层级；应先确认v.Kind() == reflect.Struct && v.CanInterface()，再直接用v.Interface()
真正难调的不是性能数字，而是反射 panic 发生在 reflect/value.go 的第 937 行，堆栈里看不到你自己的函数名。写反射代码前，先想清楚：这个需求能不能用泛型或接口约束收窄？如果能，就别碰 reflect 包。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
