不该用反射生成动态SQL，因其易致SQL注入、类型错位、字段遗漏及空值崩溃；应改用struct tag+参数化查询，或采用sqlc/ent等编译期安全工具。
为什么不该用反射生成动态SQL
Go 语言的 database/sql 本身不提供 ORM 层，但正因为如此，反射拼 SQL 是常见误区——它容易引入 SQL 注入、类型错位、字段遗漏、空值崩溃等问题。比如你用 reflect.Value.Interface() 直接转字符串塞进 SQL，nil 的 *string 会变空串，时间零值变成 '0001-01-01'，而数据库可能要求 NULL 或有非空约束。
用 struct tag + 参数化查询替代反射拼接
真正安全的做法是：用结构体字段的 db tag 标记列名，用 reflect 提取值，但只用于构造参数列表（[]interface{}），SQL 模板仍手写或由工具生成。这样既保留类型安全，又避免字符串拼接。
示例场景：插入用户记录
type User struct {
ID int64 `db:"id"`
Name string `db:"name"`
Email string `db:"email"`
Age int `db:"age"`
}
func InsertUser(db *sql.DB, u User) (int64, error) {
stmt := "INSERT INTO users (name, email, age) VALUES (?, ?, ?)"
res, err := db.Exec(stmt, u.Name, u.Email, u.Age)
// ...
}
关键点：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
stmt中不出现字段名拼接，列名和占位符顺序由代码显式控制 - 每个参数单独传入，由
database/sql驱动做类型转换和转义 - 如果字段多且易变，可用代码生成器（如
sqlc或ent）从 schema 生成 struct 和方法，而非运行时反射
真要用反射提取值？绕开 interface{} 转换陷阱
若必须动态读取结构体字段（例如通用日志记录器），别用 v.Interface() 直接转字符串。应按字段类型分别处理：
-
time.Time：用v.Interface().(time.Time).Format("2006-01-02 15:04:05")或留空传nil -
*string：先判断v.IsNil()，是则传nil，否则传*v.Elem().Interface().(string) -
sql.NullString等：检查.Valid字段，决定传值还是nil - 所有非指针基础类型（
int,string等）：直接v.Interface()即可
错误示范：fmt.Sprintf("%v", v.Interface()) —— 对 nil *string 输出 <nil></nil>，不是 SQL 的 NULL。
更稳的选择：用 sqlc 或 ent 代替手写反射逻辑
反射写一次容易，维护十次难。当表结构变化、新增字段、加索引、改类型时，反射逻辑往往漏修，导致 runtime panic 或静默数据错误。生产环境推荐：
-
sqlc：从 SQL 查询语句生成 type-safe 的 Go 函数，支持INSERT ... RETURNING、嵌套 struct、枚举映射 -
ent：声明式 schema 定义，自动生成 CRUD 方法，内置防注入、空值处理、事务封装 - 二者都跳过运行时反射，编译期报错，IDE 可跳转，字段重命名自动同步
比如 sqlc 的 query.sql 里写一句 INSERT INTO users(...) VALUES (...) RETURNING id;，就生成带完整参数校验的 CreateUser() 函数。
反射不是不能用，而是它解决的“动态性”需求，通常在编译期就能固化；硬拖到运行时，换来的是更难 debug 的边界 case 和更弱的 IDE 支持。
