为什么 reflect.StructField 的 Tag 读出来是空的
因为没用结构体字段标签（struct tag）的规范格式，或者反射时没取对字段。Go 的 struct tag 必须是反引号包裹的字符串，且 key 要和你调用 StructField.Tag.Get("key") 里的 key 完全一致，大小写敏感。
- 错误写法：
type User struct { Name string `db:name` }→field.Tag.Get("db")返回空（"db"不是 tag key，"name"才是值） - 正确写法：
type User struct { Name string `db:"name"` }→field.Tag.Get("db")返回"name" - 注意：如果字段是匿名嵌入，
reflect.Value.Field(i)可能跳过它；要用reflect.Type.Field(i)配合Anonymous字段判断是否需递归 - 常见坑：用
json:标签误当db:用，运行时不报错但映射失败，得靠日志或断点确认 tag 实际值
reflect.Value.Interface() panic: call of reflect.Value.Interface on zero Value
说明你拿到的 reflect.Value 是零值（比如对 nil 指针解引用、或字段未导出却试图取值），它没有底层 Go 值可转换。
- 典型场景：传入
nil *User给反射函数，直接reflect.ValueOf(ptr).Elem()就 panic - 安全做法：先检查
v.IsValid()和v.CanInterface()，再调v.Interface() - 导出性限制：非导出字段（小写开头）的
reflect.Value即使存在，CanInterface()也返回 false，不能转成 interface{} —— 这不是 bug，是 Go 的反射安全机制 - 绕不过去？那就别用
Interface()，改用v.String()、v.Int()等类型专用方法（但要先v.Kind() == reflect.Int判断）
用 reflect.Set() 更新结构体字段失败的三个原因
反射赋值必须满足「可寻址 + 可设置」，缺一不可。多数失败不是语法错，而是反射值来源不对。
- 传参是值类型（如
user User）：reflect.ValueOf(user).FieldByName("ID").Set(x)无效，因为user是副本，字段不可寻址 → 改传&user，再用reflect.ValueOf(&user).Elem().FieldByName("ID") - 字段不可导出：小写字段即使可寻址，
CanSet()也返回 false，Set()直接 panic - 类型不匹配：比如用
reflect.ValueOf(int64(1)).Set()赋给int字段，会 panic —— 必须保证v.Type()和目标字段类型完全一致（包括 int/int32/int64） - 额外提醒：数据库映射器里常批量设字段，建议在循环前统一做
if !v.CanSet() { continue }，避免 panic 中断整个映射流程
性能敏感时，为什么别在热路径反复调 reflect.TypeOf() 和 reflect.ValueOf()
这两个函数每次调用都触发运行时类型查找和反射对象分配，开销不小。ORM 映射器若每查一条记录都重做一次结构体解析，QPS 会明显下跌。
立即学习“go语言免费学习笔记（深入）”；
- 缓存策略：按
reflect.Type做 map 缓存，键用t.String()或uintptr(unsafe.Pointer(t))（后者更稳） - 缓存内容：字段索引数组、tag 解析结果、setter 函数（用
reflect.Value.Set()封装好，避免每次重判断） - 注意：
reflect.ValueOf(x).Type()和reflect.TypeOf(x)返回的Type可以安全比较，但不要缓存reflect.Value本身（它绑定了具体值，不能复用） - 实测差异：简单 struct（5 字段）映射，缓存 type info 后，单次反射开销从 ~200ns 降到 ~30ns
最易被忽略的一点：字段 tag 解析（比如用 strings.Split() 拆 db:"id,primary_key"）也该缓存，别每次映射都 parse 一遍 —— 这部分逻辑虽短，但在高频场景下累积起来很可观。
