reflect不能直接生成安全SQL占位符，因其仅生成“?”字符串而不参与参数绑定，易因nil指针、未导出字段、类型不匹配等导致占位符与参数数量不一致；安全做法是同步提取可导出基础类型字段值并生成等长占位符。
为什么 reflect 不能直接生成安全的 SQL 占位符参数
直接用 reflect 遍历结构体字段拼出 ?, ?, ? 看似简单，但会绕过 SQL 参数绑定机制——占位符本身不是参数值，只是“位置标记”，真正起作用的是后续 db.Query 或 db.Exec 传入的值切片。反射只负责生成占位符字符串，不参与参数绑定，更不校验类型或空值。一旦结构体字段含 nil 指针、未导出字段、嵌套结构体或时间零值，生成的占位符数和实际传参数就可能对不上，触发 sql: expected 3 arguments, got 2 这类错误。
如何用 reflect 安全提取可导出字段值并匹配占位符
核心是两步同步：先用反射拿到所有非零、可导出、基础类型的字段值（按声明顺序），再据此生成等长的 ?, ?, ? 字符串。必须跳过指针、切片、map、函数、接口等不可直接绑定的类型，否则 database/sql 会报 unsupported type。
- 用
v := reflect.ValueOf(obj)获取值对象，v.Kind() == reflect.Ptr时先v.Elem() - 遍历
v.NumField()，对每个f := v.Field(i)检查：f.CanInterface()且f.IsValid() - 过滤掉
f.Kind()为reflect.Ptr、reflect.Slice、reflect.Map、reflect.Func、reflect.Interface的字段 - 对
time.Time类型，建议显式转成time.Time值而非指针；对string、int64、bool等直接取f.Interface() - 占位符字符串用
strings.Repeat("?, ", n-1) + "?"生成，避免末尾多逗号
Scan 场景下反射还原字段值的陷阱
从数据库查出一行后用反射填充结构体字段，比插入更易出错。常见问题包括字段名大小写不匹配（如数据库列是 user_name，结构体字段是 UserName）、类型不兼容（如 DB 返回 []byte，字段定义为 string）、空值处理（sql.NullString 必须显式解包）。反射无法自动做类型转换，f.Set(reflect.ValueOf(val)) 会 panic 如果 val 类型与字段类型不严格一致。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先使用
sql.Scanner接口实现自定义扫描逻辑，而不是纯反射塞值 - 若坚持用反射，需在
f.Set()前做类型检查：f.Type() == reflect.TypeOf(val).Type() - 对
NULL值，DB 驱动通常返回nil，此时要判断f.Kind() == reflect.Ptr才能安全调用f.Set(reflect.Zero(f.Type())) - 字段标签如
json:"user_id"对 SQL 无意义，必须用db:"user_id"并手动解析标签匹配列名
更稳妥的替代方案：别硬刚反射
90% 的场景下，手写 Insert / Update 参数列表比反射更清晰、更快、更易调试。例如 db.Exec("INSERT INTO users(name, age) VALUES(?, ?)", u.Name, u.Age) 直接明了。只有当字段数极多（>20）、且频繁变动时，才值得引入反射辅助生成。此时建议封装成小工具函数，而非在业务逻辑里散落反射代码。
- 用
go:generate+ 模板生成固定 SQL 函数，避免运行时反射开销 - 用
github.com/Masterminds/squirrel这类构建器库，它内部已处理好字段映射与参数绑定 - 如果必须动态，把反射逻辑收进一个包里，对外只暴露
BuildInsertSQL(interface{}) (string, []interface{})，内部统一处理空值、时间、标签映射
反射生成占位符本身很简单，难的是让生成结果和参数值、数据库列、空值语义全部对齐。多数翻车都发生在第 3 次迭代改表结构之后——那时没人记得当初反射跳过了哪些字段类型。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
