reflect.StructField.Tag.Get本身不慢，慢在反复调用reflect.Type.Field(i)或FieldByName导致堆分配和字符串比对；应预缓存字段元数据（如索引、tag解析结果），key用uintptr(unsafe.Pointer(t))，避免热路径中重复反射。
reflect.StructField.Tag.Get 本身不慢，慢在反复调用它
很多人以为 Tag.Get 是性能瓶颈，其实不然——它只是从字符串里按 key: 截取子串，开销微乎其微。真正拖垮热点代码的，是每次都要先拿到 reflect.StructField，而这依赖 reflect.Type.Field(i) 或更糟的 reflect.Value.FieldByName。
而这两者都隐含严重开销：
-
reflect.Type.Field(i)每次调用都会复制一份reflect.StructField（含字段名、类型、tag 字符串等），触发堆分配 -
reflect.Value.FieldByName("Name")是线性遍历所有字段，逐个比对字符串——20 字段平均查 10 次，100 字段就是 50 次strcmp - 如果 tag 解析逻辑还嵌套在循环里（比如遍历 slice 中每个 struct），分配和查找就指数级放大
Tag 解析不该在热路径里做，而应预计算
结构体类型一旦编译完成，它的字段顺序、名字、tag 内容就完全固定。运行时反复解析是典型“把编译期能做的事推到运行时”。正确做法是在首次访问时一次性提取并缓存。
- 缓存目标不是
reflect.StructField本身，而是轻量结构：字段索引、是否导出、Tag.Get("json")结果、是否忽略（omitempty）等布尔标记 - key 用
uintptr(unsafe.Pointer(t))，比t.String()更快更稳，避免匿名 struct 或 vendoring 冲突 - 不要用
sync.Map存字段映射——读多写少场景下，普通map[reflect.Type]fieldMeta+sync.RWMutex实测更快 - 初始化阶段不预热全部类型，只在第一次
GetTagInfo(User{})时懒加载
Tag 字符串解析可零分配，但得绕过 reflect
如果你已经缓存了字段元数据，下一步是避免每次调用 tag.Get("json")。标准库的 StructTag.Get 会分配切片做字符串分割，而多数 tag 值格式固定（如 "json:\"id,omitempty\""），可手写解析逻辑。
- 用
strings.Index和strings.Trim替代StructTag.Get，避免切片分配 - 更激进的做法：在
go:generate阶段直接把 tag 值硬编码进生成函数，例如func (u *User) JSONKey() string { return "id" } - 注意：手写解析必须处理转义（
\"）、空格、omitempty等常见 case，否则和标准行为不一致
别让 Tag 反射混进 HTTP handler 或 DB scan 循环
最常被忽视的性能黑洞，是把反射获取 tag 的逻辑塞进高频执行路径。比如：
- 每个 HTTP 请求都
reflect.TypeOf(req.Body).FieldByName("ID").Tag.Get("json") - 数据库查询后，对每行
rows.Scan结果都重新反射解析 struct 字段与列名映射 - 日志中间件里对任意
interface{}做字段提取，且未区分 debug / prod 模式
这些地方不是“能不能用反射”的问题，而是“有没有必要在每次调用里重复做同一件事”。真正的优化点永远在边界：把反射移出循环、移出 handler、移出关键延迟路径——哪怕只省下 50ns，P99 尾部延迟也可能降掉 1ms。
