绝大多数类型检查和转换场景应优先使用 interface{} 断言而非反射，因其更直接、安全、高效；反射仅适用于运行时动态字段操作、结构体遍历及底层序列化等泛型无法覆盖的场景。
什么时候该用 interface{} 断言而不是反射
绝大多数类型检查和转换场景，接口断言更直接、更安全、也更快。比如你明确知道传入的是 *http.Request 或 io.Reader，就该用 v, ok := x.(io.Reader)，而不是绕一圈用 reflect.ValueOf(x).Interface() 再转。
- 断言失败时只产生布尔值
ok == false，无 panic 风险；反射的Value.Interface()在未导出字段或零值上调用会 panic - 编译期就能发现类型不匹配（如
x.(string)但x是int），反射则要到运行时才暴露错误 - 断言语句生成的汇编几乎就是指针比较，而反射涉及大量动态类型查找、方法表遍历、内存分配
reflect.Value.Convert() 和 reflect.Value.Interface() 容易踩的坑
这两个函数看似方便，实则边界极多。最常见的是：对非导出字段调用 Interface() 直接 panic，错误信息是 reflect: call of reflect.Value.Interface on zero Value 或 reflect: Call of unexported field。
- 必须先用
CanInterface()判断是否可安全转回接口，否则 panic 不可避免 -
Convert()要求源类型和目标类型在底层表示上兼容（比如int→int64可以，string→[]byte不行），且必须是可寻址的Value（即来自reflect.ValueOf(&x)，而非reflect.ValueOf(x)） - 从
reflect.Value转回具体类型时，别写v.Interface().(MyStruct)—— 这又嵌套了一层断言，应先确认v.Kind() == reflect.Struct且v.CanInterface() == true
反射唯一不可替代的场景：泛型尚未覆盖的动态结构操作
Go 1.18+ 的泛型能解决大部分“写一次适配多种类型”的需求，但仍有三类问题必须靠反射：
- 运行时才知道字段名（比如 ORM 根据 JSON tag 名动态赋值：
reflect.ValueOf(&obj).Elem().FieldByName(tagName).Set(...)） - 需要遍历任意结构体所有字段并统一处理（如日志脱敏、diff 计算），且字段类型不固定
- 实现类似
encoding/json这种底层序列化逻辑 —— 它必须处理任意嵌套、任意命名、任意 tag 的结构，泛型无法在编译期穷举所有组合
这类代码一旦写错，调试成本极高：panic 发生在反射调用栈深处，堆栈里看不到你自己的函数名，只有 reflect/value.go 的几十层调用。
立即学习“go语言免费学习笔记（深入）”；
性能差异不是“快 vs 慢”，而是“纳秒 vs 微秒”量级
简单断言耗时约 2–5 ns；一次完整反射流程（reflect.ValueOf + 字段查找 + Interface()）通常在 300–800 ns，差两个数量级。但这只在高频路径（如每毫秒调用上千次）才真正构成瓶颈。
- HTTP 中间件里对每个请求做一次结构体字段检查？用反射没问题
- 循环内对每个元素做
reflect.DeepEqual？立刻换成显式比较或预生成哈希 - 用反射实现 map[string]interface{} ↔ struct 转换？考虑用
mapstructure这类已优化库，它内部缓存了reflect.Type和字段偏移，避免重复解析
真正难处理的从来不是速度，而是反射把类型约束推到了运行时 —— 一个拼错的字段名、一个漏掉的 CanAddr() 判断、一个没处理的 nil 指针，都会让服务在线上突然崩掉，而且很难写单元测试覆盖全路径。
