显式类型转换比反射快10–100倍且零分配、零panic风险；反射仅适用于类型完全未知场景，如动态配置加载；v.interface()易panic且丢失类型信息，而类型断言可安全判断。
显式类型转换在绝大多数场景下比反射快 10–100 倍，且无运行时分配、零 panic 风险；反射只应在类型完全未知（如通用序列化、动态配置加载）时使用，不能因“写起来顺手”就替代类型转换。
reflect.Value.Interface() vs 类型断言：为什么一碰就 panic
当你写 v.Interface()，它返回的是 interface{}，不是原始类型——后续若想调用方法或访问字段，必须再做一次类型断言，比如 v.Interface().(*MyStruct)。这不仅多一次接口解包开销，更关键的是：如果 v 是零值、未导出字段、或底层类型不匹配，v.Interface() 直接 panic，而类型断言 v.(T) 至少还能用 ok 形式安全判断。
-
reflect.ValueOf(x).Interface()在x是未导出字段或 nil 指针时会 panic，而x.(T)只是返回零值 + false - 类型断言编译期可验证，IDE 能跳转、能补全；
Interface()后的类型信息彻底丢失，只能靠文档或运行时日志猜 - 每次
Interface()都触发堆分配（哪怕返回的是基本类型），而类型断言不分配内存
FieldByName("Name") vs 直接 v.Field(0)：O(n) 查找有多伤
对一个 15 字段的 struct 调用 v.FieldByName("Name")，内部要遍历所有导出字段、逐个比较字符串，平均查 7–8 次才命中；而 v.Field(0) 就是数组下标访问，CPU 几个周期搞定。基准测试显示，前者比后者慢 6–9 倍，且字段越多差距越大。
- 字段名固定时，硬编码索引（如
v.Field(1).SetString("foo")）是最简单有效的提速方式 - 若字段名来自配置（如 JSON key 映射），必须提前构建
map[string]int缓存索引，而不是每次调用都FieldByName -
FieldByName不支持非导出字段，即使你加了json:"name"tag，也查不到——得先用v.Field(i)遍历再检查Tag.Get("json")
reflect.TypeOf(x) 放在循环里等于自废武功
每次调用 reflect.TypeOf(x) 都要查全局类型表、构造新 reflect.Type 对象、触发接口转换；在 HTTP 请求处理循环中每请求调一次，性能损耗远超你想象。实测单次调用比直接读取缓存的 reflect.Type 慢 30–50ns，高频服务下每秒万级请求就是毫秒级累积延迟。
- 正确做法：按
uintptr(unsafe.Pointer(t))为 key 缓存reflect.Type和字段元数据，避免字符串拼接或t.String()作 key - 别缓存
reflect.Value实例——它绑定具体值，不可复用，且无法做 map key - 初始化阶段不预热所有类型，只在首次遇到某
reflect.Type时解析并缓存，否则浪费内存
什么时候该砍掉反射，改用生成代码
如果你的反射逻辑满足「类型固定 + 操作模式统一」，比如所有 API 请求结构体都要从 map[string]string 解析、所有 DB 模型都要生成 INSERT SQL，那 runtime 反射就是在给编译器添堵。这时候 go:generate 生成的函数，性能接近原生，且 IDE 支持完整、无 panic 风险。
- 典型信号：你在写
if t.Kind() == reflect.Struct { ... }+ 大段字段遍历 + tag 解析，且这些 struct 全在本项目里定义 - ent、sqlboiler、stringer 这类工具本质就是把反射逻辑移到编译期，运行时零开销
- 最危险的中间态：既用生成代码又留反射兜底——维护两套逻辑，性能还卡在反射瓶颈上
真正难绕开的，是那些连字段名都得从外部输入决定的场景，比如用户上传 YAML 配置后动态构造 struct 实例；这种时候，反射不是选项，是唯一路径。但请记住：每一次 CanInterface() 漏判、每一次 FieldByName 落空、每一次没检查 IsValid()，都在把程序往 panic 边缘推。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
