应避免在高频路径中重复使用反射，优先缓存类型信息、改用泛型或接口，ORM映射需预计算字段信息，强类型场景宜用编译期生成代码替代运行时反射。

高频请求路径中调用 reflect.ValueOf 或 reflect.TypeOf

这类操作在每次 HTTP handler、gRPC 方法或消息解析入口处反复执行，会显著拖慢吞吐。比如一个每秒处理 10k 请求的服务，若每个请求都对入参结构体做 reflect.ValueOf(req).NumField()，实际开销可能比直接字段访问高 50 倍以上。

• 真实场景：JSON 反序列化前手动遍历 struct 字段校验——应改用 json.Unmarshal + 自定义 UnmarshalJSON 方法，或用 encoding/json 的 tag 控制
• 替代做法：把反射逻辑移到 init() 函数里缓存 reflect.Type 和字段偏移，后续只查表
• 坑点：缓存未加锁或用了非线程安全的 map，导致 panic；或忘记处理指针解引用（v.Elem() 漏判）

编译期已知类型却仍用 interface{} + 反射做类型分发

当你的函数参数只有几种固定类型（如 int、string、time.Time），还写一堆 if v.Kind() == reflect.String 分支，既慢又难维护。

• 更优解：用泛型（Go 1.18+）重写，例如 func Format[T int | string | time.Time](v T) string，零运行时开销
• 次选方案：定义接口（如 Stringer、Formatter），让各类型自行实现，调用方只管 v.Format()
• 典型错误：为“统一处理所有类型”硬塞反射，结果发现 90% 的调用都是 string，却每次都走完整反射流程

ORM 或配置映射中未缓存结构体元信息

像 GORM、SQLx 这类库内部确实要用反射，但它们都在首次使用时就完成字段扫描并缓存。如果你自己手写映射逻辑，每次查询都重新 reflect.StructOf 或 v.FieldByName，性能立刻崩盘。

• 实操建议：用 sync.Map 缓存 map[reflect.Type][]fieldInfo，key 是结构体类型，value 是预计算的字段名→索引映射
• 注意边界：嵌套结构体、匿名字段、tag 解析（如 json:"user_id"）必须在缓存阶段一并处理好，否则运行时再解析就白缓了
• 容易漏掉的点：没处理指针接收者方法，导致 v.MethodByName 查不到——得先 v.Addr().MethodByName

需要强类型安全或静态检查的场景下依赖反射

反射绕过编译器检查，字段名拼错、类型不匹配、非导出字段误改，全在运行时报 panic: reflect: call of reflect.Value.Interface on zero Value 或更模糊的 invalid memory address。

• 典型翻车：YAML 配置加载后用反射赋值到 struct，但 struct 字段名从 UserName 改成 Username，编译不报错，启动就 panic
• 防御做法：在初始化时用反射做一次“元信息校验”，比如检查所有 tag 字段是否真有对应 struct 字段，失败则 log.Fatal
• 更稳妥的路：用 go:generate 工具（如 stringer、easyjson）在构建时生成类型专用代码，彻底消灭运行时反射

最常被忽略的一点是：反射不是“写出来就能跑”，它把本该在编译期暴露的问题，拖到服务上线后第一笔请求才爆发。而修复成本远不止改一行代码——要补缓存、加校验、写测试、压测验证。不如一开始就想清楚：这个灵活性，是不是真值得拿确定性换。