应缓存 reflect.Type 和预计算字段偏移，避免在热路径调用 reflect.ValueOf 或 FieldByName；前者引发堆分配加剧 GC 压力，后者为 O(n) 线性查找，均应替换为初始化时缓存 Type、构建字段名到索引映射及 fieldInfo 结构体。
直接缓存 reflect.Type 和预计算字段偏移，别在循环里调用 reflect.ValueOf 或 FieldByName——这是最有效、也最容易被忽略的两步。
为什么 reflect.ValueOf 不能进热路径
每次调用 reflect.ValueOf 都会触发逃逸分析失败，生成新 reflect.Value 实例并分配堆内存；高频场景（如 HTTP 请求体解析）下，GC 压力会陡增，实测 p99 延迟可跳升 1–2ms。
常见错误现象：
- 把
reflect.ValueOf(obj)放在 handler 函数内部反复调用 - 对同一个结构体类型，每次解码都重新走
v.FieldByName("ID")
正确做法：
- 只在初始化阶段调用一次
reflect.TypeOf(&T{})，缓存其指针地址作为 key - 用
uintptr(unsafe.Pointer(t))当 map key，避免字符串拼接开销 - 后续所有操作基于缓存的
reflect.Type和预构建的字段索引表
FieldByName 是 O(n) 查找，必须换成 Field(i)
FieldByName 内部是线性遍历所有字段做字符串比对，一个 50 字段的 struct 就要比较 50 次；而 Field(i) 是数组下标访问，常数时间。
使用场景：
- ORM 字段映射：
db.Column("user_name") → struct field index 2 - JSON tag 解析：
json:"id,string"对应固定字段位置
实操建议：
- 启动时遍历
t.NumField()，构建map[string]int字段名到索引的映射 - 字段名冲突或大小写敏感时，额外加一层
strings.ToLower转换（仅首次） - 别用
sync.Map存这个映射——读多写少，普通map+sync.RWMutex更快
字段级元数据缓存比裸 StructField 更实用
直接缓存 []reflect.StructField 仍需每次调用 .Tag.Get 和 .Type.Kind()，这些仍是运行时查表操作。
推荐缓存结构：
type fieldInfo struct {
Name string
Offset uintptr
Tag string
IsExported bool
Kind reflect.Kind
}
这样做的好处：
-
Offset可用于后续unsafe直接取值，绕过反射调用 -
Tag已解析好，无需重复tag.Get("json") -
IsExported避免运行时再判断CanInterface()导致 panic
注意点：
- 结构体字段顺序变更会导致
Offset失效，但只要不改字段定义，就稳定 - 不要在
init()里预热所有可能用到的类型——按需加载，否则浪费内存
真正难处理的是嵌套结构体和接口字段的递归映射，这时候缓存粒度得下探到每个子类型，且必须控制递归深度，否则容易栈溢出或无限循环。这类逻辑一旦写错，性能问题会藏得很深，调试时往往要靠 pprof 的 allocs profile 才能定位到具体哪一行在疯狂分配 reflect.Value。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
