StructTag.Get("json") 性能差因每次调用都重新解析tag字符串，单次耗时150–250ns；应缓存解析结果，统一用*Struct类型获取reflect.Type作key，并注意私有字段读tag安全但取值需检查CanInterface。
StructTag.Get("json") 每次调用都重新解析，性能确实差
不是“有点慢”，是高频场景下会明显拖垮吞吐。每次 field.Tag.Get("json") 都会做三件事：把原始 tag 字符串（如 `json:"name,omitempty"`）按空格切分、遍历 key-value 对、再对匹配项做引号清理和逗号截断。单次约 150–250ns，QPS 10k 的接口里每秒多花 1–2ms CPU 时间，p99 延迟肉眼可见上浮。
常见错误现象：
在 HTTP handler 循环里反复调用 sf.Tag.Get("json")；或在 ORM 扫描 1000 行数据时，对每个 struct 实例都重新遍历字段+读 tag。
- 别在循环体里调
field.Tag.Get，哪怕只是取一个字段 - 不要以为 “只读不写就没事”——
Get本身就有开销，和是否修改无关 - 标签值不变，但解析逻辑每次重跑，这是纯浪费
缓存 StructTag 解析结果必须用正确的 Type key
缓存能压掉 90%+ 的 tag 解析开销，但 key 错了等于没缓存。Go 反射系统里，reflect.TypeOf(YourStruct{}) 和 reflect.TypeOf((*YourStruct)(nil)).Elem() 是两个完全不同的 reflect.Type 实例，哪怕它们指向同一个结构体。
实测中，用值类型做 key 导致缓存命中率始终为 0，所有请求都走慢路径。
立即学习“go语言免费学习笔记（深入）”；
- 统一用
t := reflect.TypeOf((*YourStruct)(nil)).Elem()构建缓存 key - 缓存 value 推荐用
map[string]string存字段名 → 解析后 json 名映射，比如{"Name": "name", "Email": "email"} - 初始化用
sync.Once，避免竞态；查表用map[reflect.Type]map[string]string，别嵌套太深
手动解析 Tag 字符串极易出错，别自己 Split 或正则
有人图快直接 strings.Split(string(field.Tag), " ") 然后硬找 json:，这在真实项目里几乎必崩。因为 tag 原始字符串是带双引号的字面量：`json:"user_name,omitempty"` → string(field.Tag) 返回的是 "json:\"user_name,omitempty\""，中间有转义、空格不规则、还可能含换行。
field.Tag.Get("json") 内部已处理这些边界，它返回的是干净的 "user_name,omitempty"（注意：仍带双引号，需 strings.Trim）。
- 永远别用
string(field.Tag)当原始字符串解析——它不是你想的那样 - 别用
strings.FieldsFunc或正则切分修饰符，strings.SplitN(trimmed, ",", 2)更快更稳 - 若只关心主字段名（忽略
omitempty），用strings.SplitN(trimmed, ",", 2)[0]即可，不用完整 parser
未导出字段的 Tag 可读但值不可取，这个边界常被忽略
field.Tag.Get("json") 对小写字段（如 name string `json:"name"`）完全安全，能拿到 tag；但一旦后续调用 field.Interface() 或 field.Set() 就 panic。很多 ORM 在字段映射阶段没检查 field.CanInterface()，一碰到私有字段就 crash。
更隐蔽的问题是：缓存 tag 时如果没一并缓存 field.CanInterface() 结果，下次查表还得重复判断——而这个判断本身也有开销。
- 读 tag 前不用检查导出性，放心调
.Get - 取值前必须加
if field.CanInterface() { ... }，否则必 panic - 缓存结构里建议存
[]struct{ Name, JSON string, CanSet bool }，避免每次反射都触发运行时检查
Get 返回值带引号这个细节，三者任何一个出错，优化就白做了。 
