正确做法是优先通过反射读取结构体字段的 db 标签（如 sf.Tag.Get("db")），若为空则 fallback 到字段名并检查 sf.IsExported()；需区分零值语义、指针 nil 与字段排除逻辑，且应缓存反射结果提升性能。
用 reflect 读结构体字段时，别直接用 StructField.Name
Go 的反射默认拿到的是字段名（如 User.Name → "Name"），但实际数据库字段常是 user_name 或 nick_name。硬编码映射或手写 SQL 容易出错且难维护。
正确做法是优先读取结构体标签（struct tag）里的 db 字段：
type User struct {
ID int64 `db:"id"`
Name string `db:"user_name"`
Email string `db:"email_addr"`
}
反射中用 sf.Tag.Get("db") 获取，若为空再 fallback 到 sf.Name（可转小写下划线，但不推荐自动转换——语义易歧义，比如 HTTPClient → h_t_t_p_client）。
- 必须检查
sf.IsExported()，私有字段无法被反射读取值，跳过或 panic 都比静默忽略好 - 避免用
strings.ToLower(sf.Name)简单转小写：Go 字段名首字母大写是约定，但大小写混合词（如APIKey）不能靠规则可靠转成api_key - 标签值为空字符串（
db:""）应视为“排除该字段”，不是“用原名”
生成 INSERT 语句时，reflect.Value 的零值要显式处理
反射取值后，v.Interface() 拿到的是真实值，但像 int64、string、*time.Time 这些类型，零值（0、""、nil）是否插入数据库，取决于业务逻辑，不是反射能替你决定的。
立即学习“go语言免费学习笔记（深入）”；
常见错误是把所有非空字段都塞进 INSERT，结果 status 字段为 0 被写入，而其实它该用数据库默认值。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对指针类型（
*T），先用v.IsNil()判断是否跳过；对值类型（T），用v.IsZero()+ 白名单字段控制（比如只对ID允许为零值插入） - 不要依赖
v.Kind() == reflect.Ptr && !v.IsNil()就直接取v.Elem().Interface()—— 如果v.Elem()是未初始化的 struct，Interface()会 panic - INSERT 的
VALUES占位符一律用$1, $2, ...（PostgreSQL）或?, ?, ...（MySQL），别拼字符串，防止 SQL 注入
UPDATE 语句必须区分“字段未设置”和“字段设为零值”
这是反射生成 SQL 最容易翻车的地方。用户调用 UpdateUser(&User{ID: 123, Name: ""})，你是该更新 name = ''，还是忽略 Name 字段？反射本身无法区分。
解决方法只有两个：要么要求字段用指针（*string），靠 nil 表示“未设置”；要么引入额外标记（如自定义 tag db:",omitempty"，类似 JSON）。
- 推荐用指针字段：反射中判断
v.Kind() == reflect.Ptr && v.IsNil()→ 跳过该字段；否则用v.Elem().Interface() - 如果结构体混用值类型和指针类型，必须按字段单独配置策略，不能全局统一处理
- 别在反射循环里做
if v.Interface() != nil——v.Interface()返回interface{}，nil比较永远为 false；要用v.Kind() == reflect.Ptr && v.IsNil()
性能敏感场景下，缓存 reflect.Type 和字段解析结果
每次调用都走一遍 reflect.TypeOf(v).NumField() + 循环读 tag，开销不小，尤其在高频 INSERT/UPDATE 场景（如日志写入、消息消费）。
可以提前为每种 struct 类型构建一个元信息结构体，缓存字段名、DB 名、是否可空、是否跳过等，并用 sync.Map 存 reflect.Type → 元信息 的映射。
- 缓存 key 必须用
t.String()或fmt.Sprintf("%s.%s", t.PkgPath(), t.Name())，不能用t本身（reflect.Type不可比较） - 首次解析失败（如 tag 格式错）要记录日志并 panic，别静默 fallback —— 后续缓存会让问题更隐蔽
- 如果用了 ORM（如 GORM），它的字段解析已高度优化，自己手写反射生成 SQL 反而可能更慢，先 benchmark 再决定是否造轮子
字段名映射和零值语义是两套独立逻辑，混在一起处理一定会漏 case。宁可多写几个 if，也不要试图用一个通用函数覆盖所有结构体。
