Go反射性能差，优化应优先用泛型替代、缓存反射对象、代码生成代替运行时反射、避免热路径使用反射。
Go 语言中反射（reflect）功能强大，但代价明显：运行时类型检查、动态方法调用、结构体字段遍历等操作比直接调用慢数倍甚至数十倍。减少反射开销的核心思路是——能静态解决的，绝不 runtime 反射。以下是一些经过验证、可落地的优化策略。
优先使用泛型替代反射
Go 1.18+ 泛型可覆盖大量原本依赖反射的场景，如通用容器、序列化适配器、比较函数等。泛型在编译期生成特化代码，零运行时开销。
- ❌ 反射写法（低效）：
func Equal(a, b interface{}) bool {
return reflect.DeepEqual(a, b)
}
- ✅ 泛型写法（高效）：
func Equal[T comparable](a, b T) bool {
return a == b
}
对 slice/map 等复杂类型，也可结合约束（constraints）和递归泛型实现类型安全的深度比较，避免 reflect.DeepEqual 的全部开销。
缓存反射对象，复用而非重建
若必须用反射（如 ORM 字段映射、JSON 序列化中间层），应避免每次调用都执行 reflect.TypeOf 或 reflect.ValueOf。这些操作本身就有显著成本。
立即学习“go语言免费学习笔记（深入）”；
- 将
reflect.Type和常用reflect.Value（如结构体字段描述）在初始化或首次访问时缓存到全局 map 或 sync.Map 中 - 对固定结构体类型（如数据库模型），可预生成字段索引数组、getter/setter 函数闭包，后续直接调用
- 示例：缓存 struct 字段名与偏移量映射
var typeCache sync.Map // map[reflect.Type][]fieldInfo
用代码生成（go:generate）代替运行时反射
对已知结构体（如 API 请求/响应体、数据库实体），用 go:generate + go/types 或 ast 包在构建阶段生成类型专用代码，彻底消除运行时反射。
- 常见工具：
stringer、easyjson、gqlgen、自定义gotpl模板 - 例如：为
User结构体生成 JSON 编解码器，性能接近encoding/json的标准库实现，但无反射路径 - 优势：编译期完成，零 runtime 开销；IDE 支持好；可做类型校验和字段级控制
避免在热路径中使用反射
高频调用逻辑（如 HTTP handler 内部、循环体、定时任务核心）严禁出现 reflect.Value.Call、reflect.StructField 遍历等操作。
- 把反射相关初始化移到 init() 或服务启动阶段
- 热路径只调用预生成的函数指针或接口方法，如：
encoderFunc := cachedEncoders[typ]，然后encoderFunc(data) - 用 pprof 分析 CPU profile，定位并标记出
reflect.*占比高的调用栈，针对性重构
