StructTag 的 key 必须完全匹配、大小写敏感且无空格，如 json:"name" 才能用 Tag.Get("json") 获取；若为 JSON:"name" 或 json: "name" 则返回空字符串。
StructTag 里的 key:value 怎么取才不 panic
直接用 reflect.StructField.Tag.Get("json") 拿不到值？因为 tag 是 raw string，冒号前的 key 必须完全匹配，大小写敏感，且不能带空格。比如 json:"name" 能被 "json" 取到，但 JSON:"name" 或 json: "name" 就会返回空字符串。
常见错误是把 struct tag 当成 map 解析，其实它只是个带规则的字符串。Go 标准库用 reflect.StructTag.Lookup 做了简单切分，只认第一个冒号前的 key，后面全当 value。
- 别自己
strings.Split(tag, ":")—— 会错判嵌套引号里的冒号，比如json:"user_id,string" - 要用
tag.Get("json")，不是tag.Get("JSON") - 如果 tag 是
json:"-"（末尾有空格），Get仍返回"-"，但后续解析时需手动 trim 空格再判断是否忽略字段
json.Marshal 为啥忽略 struct 字段
不是字段没导出，而是 json tag 显式设成了 -，或者字段名首字母小写（未导出）且没配 tag。注意：即使写了 json:"name"，字段仍必须导出（大写开头），否则 json.Marshal 直接跳过，连 tag 都不看。
容易踩的坑是混用 map[string]interface{} 和 struct：map 里 key 是字符串，struct 里字段是标识符，tag 只在 struct 反射时起作用。
立即学习“go语言免费学习笔记（深入）”；
-
json:"name,omitempty"在值为零值时跳过该字段，但omitempty不影响-的强制忽略行为 -
json:"name,string"表示把底层类型（如 int）转成字符串序列化，但若字段本身是*int且为 nil，仍会输出null，不会报错 - 嵌套 struct 中某字段 tag 设为
-，外层 marshal 时该字段彻底消失，不会留空对象
自定义 UnmarshalJSON 时怎么读 struct tag
实现 UnmarshalJSON 方法后，标准 json 包就不再自动解析 tag，得自己动手。这时候不能依赖 json.Unmarshal 内部逻辑，要手动调用 reflect.StructTag.Get 拿配置，再按需处理字节流。
典型场景是兼容多种字段名（如 API 返回可能是 user_name 或 userName），或需要对某个字段做特殊类型转换（如时间戳转 time.Time）。
- 别在
UnmarshalJSON里重复调用json.Unmarshal(b, &tmp)到临时 struct —— 可能触发无限递归 - 用
json.RawMessage暂存字段原始 bytes，再根据 tag 决定如何解析，避免提前 decode 失败 - 如果字段 tag 含
string，解析时要检查原始 JSON 是否为字符串，否则json.Unmarshal会报invalid type for json.Number类错误
StructTag 解析性能真有影响吗
单次反射取 tag 几乎无开销，但高频场景（如每秒万级 HTTP 请求解析 JSON）下，反复调用 reflect.TypeOf(x).Field(i).Tag.Get 会成为瓶颈。原因是每次都要做字符串查找 + 分割，且 reflect 操作本身有 runtime 开销。
真正慢的不是 tag 解析，而是整个 struct 反射路径 —— 字段遍历、类型检查、内存拷贝。tag 只是其中一环。
- 启动时缓存
map[reflect.Type]map[string]fieldInfo，避免运行时重复解析 tag - 用
unsafe或 code generation（如easyjson）绕过反射，tag 提前编译进序列化逻辑 - 别为了“省一次 Get”把 tag 值硬编码进逻辑 —— 维护成本远高于那点 CPU 时间
tag 解析本身不复杂，但它是反射链路上最常被忽视的一环；一旦开始优化，往往发现真正卡住的是字段循环和 interface{} 转换。
