不能用reflect直接拼SQL字符串，因其易致panic、SQL注入和类型错乱；反射仅用于解析db标签、构建字段-列名映射表，SQL执行必须依赖预编译参数绑定。
直接用 reflect 拼 SQL 字符串是危险且不可维护的，它不能替代预编译语句和参数绑定；真正可用的“反射生成 SQL 工具”，只应在元数据映射阶段介入——比如解析 db 标签、推导表名、构建字段名到列名的映射表，其余全部交给 database/sql 或 sqlx 处理。
为什么不能用 reflect.Value.Interface() 直接拼 INSERT 语句
常见错误是写类似 fmt.Sprintf("INSERT INTO user (name) VALUES ('%s')", v.FieldByName("Name").Interface()) 这种代码。它有三个硬伤：
-
v.Interface()对指针字段（如*string）不判空就调用，会 panic：invalid memory address or nil pointer dereference - 字符串值未转义，用户输入
O'Reilly会导致 SQL 语法错误甚至注入 - 时间、JSON、自定义类型（如
type UserID int64）丢失Value()方法语义，写入数据库时类型错乱
正确提取结构体字段与 db 标签映射关系
目标不是“拼 SQL”，而是建立 struct field → column name 的可靠映射。关键在过滤和递归控制：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
reflect.TypeOf(v).NumField()遍历，跳过非导出字段（首字母小写）——reflect无法访问它们 - 对每个
field调用field.Tag.Get("db")；若返回空字符串或"-"，跳过该字段 - 若
field.Anonymous == true且field.Tag.Get("db") == ",inline"，递归处理其字段，并用当前字段名作前缀（如extra_created_at） - 绝不依赖
FieldByName()动态取字段——它查的是字段名，不是标签值；匹配列名应靠 tag 映射表 +rows.Columns()返回的实际列名
如何安全地把反射映射结果喂给 database/sql
反射只管“知道该传什么”，不负责“怎么传”。最终执行必须走标准参数化流程：
立即学习“go语言免费学习笔记（深入）”；
- 构造占位符列表（如
[]string{"?", "?", "?"}）和参数值切片（[]interface{}{v1, v2, v3}），二者长度严格一致 - 对每个字段值，先检查是否为指针且
IsNil()；若是，按业务决定填nil（对应 SQLNULL）还是跳过 - 值类型为
time.Time、json.RawMessage等，直接塞进[]interface{}即可——database/sql内部会调用其Value()方法 - 绝不要把反射生成的 SQL 字符串传给
db.Query()；它必须是静态字面量或确定性拼接（如"SELECT * FROM " + tableName是允许的，但前提是tableName来自白名单）
最易被忽略的一点：字段映射逻辑（尤其是带 ,inline 的嵌套结构）必须缓存。每次查询都 reflect.TypeOf() + 全量遍历，性能损耗远超预期——应以 reflect.Type 为 key 缓存 map[string]string 映射表。
