reflect.StructField.Tag 是 reflect.StructTag 类型而非字符串，需用 Tag.Get("key") 安全提取值；传指针给 reflect.TypeOf 时须先 Elem() 再 NumField()；非导出字段反射不可见；高频场景应缓存 reflect.Type 和字段索引。
为什么 reflect.StructField.Tag 不能直接当字符串用
结构体字段的标签（如 `json:"name,omitempty"`）在反射中被解析为 reflect.StructTag 类型，它不是原始字符串，而是一个带解析能力的结构体。直接用 string(field.Tag) 得到的是原始字面量（含反引号和空格），无法安全提取键值对。
常见错误现象：手动 strings.Split 或正则匹配，结果在含空格、逗号嵌套、转义引号时崩溃；或忽略 tag 中多个 key 的优先级（如 json 和 db 并存时逻辑错乱）。
- 必须调用
field.Tag.Get("json")，它内部已处理引号剥离、空格归一、key 重复覆盖等细节 -
Get返回空字符串表示该 key 不存在，不会 panic，适合条件分支 - 若需遍历所有 key（比如同时支持
json、yaml、validate），可用map[string]string手动解析field.Tag字符串，但应复用标准库的reflect.StructTag解析逻辑，而非重写
reflect.TypeOf 传指针还是值？影响 NumField 调用是否 panic
对结构体变量调用 reflect.TypeOf 时，若传入的是指针（如 &User{}），返回的 reflect.Type 是指针类型，其 Kind() 为 reflect.Ptr，此时直接调用 NumField() 会 panic：“reflect: NumField of non-struct type”。这是最常踩的坑。
使用场景：ORM 映射、JSON 解码通常接收 interface{}，底层可能是值也可能是指针，必须统一处理。
立即学习“go语言免费学习笔记（深入）”；
- 检查
t.Kind() == reflect.Ptr，成立则先调用t.Elem()获取所指向的结构体类型 - 若不确定输入来源，建议统一要求传指针（如
json.Unmarshal的行为），或在函数入口做自动解包 -
reflect.ValueOf同理：传指针后需先.Elem()才能读写字段值，否则.Field(i)会 panic 或返回不可寻址的副本
结构体字段必须导出才能被反射读取标签
Go 反射无法访问非导出（小写开头）字段，无论是否带 tag。这不是 bug，而是语言设计约束：reflect 只能操作可导出的标识符，这是类型安全与封装边界的体现。
典型问题：定义了 type User struct { name string `json:"name"` }，反射遍历时字段数为 0，NumField() 返回 0，且无任何错误提示。
- 字段名首字母必须大写（如
Name），否则反射完全“看不见”该字段 - tag 内容本身可以是小写（如
`json:"user_name"`），这不影响，但字段名本身必须可导出 - 如果业务逻辑强制要求字段私有，只能改用组合+导出嵌入结构体，或放弃反射，改用代码生成（如
go:generate）
性能敏感场景下，避免在热路径反复调用 reflect.TypeOf 和 reflect.ValueOf
每次调用 reflect.TypeOf 或 reflect.ValueOf 都会分配新对象并做类型检查，开销远高于普通函数调用。在 HTTP handler、数据库扫描循环等高频路径中，反复反射同一结构体类型会造成明显 GC 压力和延迟。
容易被忽略的地方：很多人只缓存了 reflect.Type，却忘了 reflect.Value 的构造成本同样高，尤其当需要频繁 .Field(i).Interface() 时。
- 对固定结构体类型，应在 init 或首次使用时缓存
reflect.Type和常用字段索引（如nameIndex := t.FieldByName("Name").Index[0]） - 避免在循环内对每个元素都调用
reflect.ValueOf(item)；改为先获取reflect.Value模板，再用.SetMapIndex或.SetIndex复用 - 真正极致的性能需求（如序列化库），应结合
unsafe或 code generation 绕过反射，但代价是维护复杂度上升
