reflect不能安全生成SQL语句，因其仅读取结构体元信息，不参与SQL构建；字段须导出、禁用FieldByName、指针需判空、自定义类型须调Value()方法，最终应传[]interface{}给db.Exec。
reflect 不能安全、完整地生成可执行的 SQL 语句——这不是能力问题，而是设计边界问题。它只负责读取结构体元信息（字段名、类型、db 标签），不参与 SQL 构建、参数绑定或语义校验。强行用 reflect.Value.Interface() 拼字符串，大概率导致 SQL 注入、nil panic、时间格式错乱或主键误写。
下面直击实际开发中最常卡住的三个环节，每个都对应真实报错和可粘贴验证的代码片段。
反射遍历结构体字段时 FieldByName 返回空值
常见错误现象：reflect.Value.FieldByName("name").IsValid() 返回 false，后续拼字段名直接丢列。
原因不是 tag 写错了，而是字段未导出：Go 反射无法访问小写字母开头的字段，哪怕写了 db:"user_name" 也无效。
实操建议：
- 结构体字段必须首字母大写，例如
UserName string `db:"user_name"` - 不要用
FieldByName查找字段——它依赖名字精确匹配，而你真正需要的是「所有带有效db标签的导出字段」 - 改用
reflect.TypeOf(t).NumField()遍历，对每个field调用field.Tag.Get("db")判空再处理 - 遇到
field.Anonymous == true且tag == ",inline"，需递归展开并加前缀（如extra_created_at）
拼 WHERE 条件时因 nil 指针 panic
常见错误现象：reflect.Value.Interface() 触发 panic: reflect: call of reflect.Value.Interface on zero Value 或更隐蔽的 nil pointer dereference。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
根源是字段为 *string、*int64 等指针类型，且值为 nil，但代码没做解引用前检查。
实操建议：
- 对每个
v reflect.Value，先判断v.Kind() == reflect.Ptr && v.IsNil() - 若为
nil，跳过该字段，或按业务生成"col IS NULL"子句（别硬塞NULL字符串） - 非 nil 时才调
v = v.Elem()解引用，再继续取值 - 接口类型（
interface{}）要额外用v.Kind() == reflect.Interface && !v.IsNil()判空，否则v.Elem()会 panic
INSERT 语句中自定义类型写入失败
常见错误现象：字段是 type UserID int64 或实现了 driver.Valuer 的时间类型，但反射后直接 v.Interface() 塞进 fmt.Sprintf，导致数据库收到 0、空字符串或类型不匹配错误。
根本原因是绕过了 Go 数据库驱动的类型协商机制——database/sql 依赖 Value() 方法做安全转换，而反射拼字符串跳过了这层。
实操建议：
- 基础类型（
int、string、bool）可安全用v.Interface() - 自定义类型必须显式调用
v.Interface().(driver.Valuer).Value()获取 DB 可识别值 - 更稳妥的做法：不拼 SQL 字符串，而是把
[]interface{}交给db.Exec(query, args...)，让标准库自己处理转换 - 永远避免
fmt.Sprintf("INSERT INTO t (a) VALUES (%v)", v.Interface())这类写法
reflect 提取 db 标签映射关系 → 缓存成 map[string]string（字段名→列名）→ 生成静态占位符字符串（如 "INSERT INTO user (id, name) VALUES (?, ?)"）→ 把结构体字段值转成 []interface{} 传给 db.Exec。中间任何一步试图用反射“动态拼 SQL 字符串”，都在挑战 Go 类型系统和 SQL 安全底线。 
