安全反射生成SQL需先做元数据映射，再参数化拼接；必须检查指针nil、字段导出性、db标签有效性、嵌入结构及驱动参数格式一致性，否则易panic或写错数据。
直接用反射批量生成 SQL 语句是高危操作，不推荐裸写。真正安全高效的做法是：只用反射做元数据映射（字段名 → 列名、类型判断、标签读取），SQL 拼接阶段必须走参数化，且结构体字段需显式控制空值与 NULL 语义。
reflect.Value.Interface() panic：nil 指针未检查就取值
这是最常触发崩溃的点——尤其字段是 *string、*int64 等指针类型且值为 nil 时，直接调 v.Interface() 就 panic。
- 必须先判断：
v.Kind() == reflect.Ptr && v.IsNil()，满足则跳过该字段，或按业务生成"col IS NULL" -
v.IsValid()对 nil 指针也返回true，不能代替v.IsNil() - 若字段是
interface{}类型，得先v.Elem()解一层再判 nil，否则v.Interface()可能返回空interface{}而非底层值
结构体字段名和数据库列名不一致？用 db tag + 缓存反射元信息
别用 map[string]interface{} 做条件拼接，它丢失类型、无法校验字段是否导出、易混淆 nil 和空字符串。
- 定义结构体时加
db标签，例如：Name *string `db:"user_name"` - 遍历字段时用
field.Tag.Get("db")获取列名；返回空字符串则跳过，返回"-"显式忽略 - 反射元信息（如字段名→列名映射）应缓存，避免每次查询都调
reflect.TypeOf()+ 全量遍历 - 遇到匿名嵌入字段（
Extra Info `db:",inline"`），需递归展开并拼前缀，如"extra_created_at"
WHERE 条件动态拼接：命名参数 vs 位置参数要提前对齐
选 sqlx.Named 还是原生 database/sql，决定了反射阶段的数据组织方式。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
sqlx.Named：保持传入结构体或 map 不变，占位符写成:name，由 sqlx 自动绑定 - 用原生
db.Query：必须拆成两个切片——args = append(args, v.Interface())，同时维护placeholders列表（如"?"），数量严格对应 - 绝对不要把命名占位符（
:name）混进原生驱动的 SQL 字符串里，它不会识别，变成字面量，查不到数据还不报错 - 处理
IN (?)场景时，用v.Kind() == reflect.Slice判断，并用v.Len()动态生成等量"?"
INSERT/SELECT 语句生成：字段必须导出，且不能依赖 FieldByName
小写字段（如 name string）哪怕有 db:"user_name" 标签，reflect.Value.FieldByName("name") 也返回无效值，因为 Go 反射不访问未导出字段。
- 结构体字段名必须首字母大写，例如：
UserName string `db:"user_name"` - 若需兼容 legacy 小写字段，只能用
reflect.TypeOf(v).NumField()遍历所有字段，再比对Tag.Get("db")匹配，不能靠FieldByName -
Tag.Get("db")本身不会 panic，但后续如strings.Split(tag, " ")[0]会——务必先判空再操作 - 自定义类型（如
type UserID int64）应显式调v.Interface().(driver.Valuer).Value()，避免绕过Value()方法导致写入异常
真正难的不是“怎么拼出 SQL 字符串”，而是确保每一步反射操作都落在可预测、可终止、可验证的边界内：字段是否导出、指针是否为 nil、tag 是否为空、嵌入是否 inline、参数格式是否与驱动对齐——漏掉任意一环，都会在运行时悄无声息地崩掉或写错数据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
