反射拼WHERE条件易出错的核心在于字段过滤、空值处理、占位符对齐三步未严控：需确保字段导出、nil指针跳过、IN子句动态生成等长占位符，并严格使用?位置参数。
直接用反射拼 WHERE 条件很容易生成无效 SQL 或 panic，核心问题不在“会不会用 reflect.Value”，而在于**字段过滤、空值处理、占位符对齐**这三步没做严。
反射遍历结构体时字段突然消失？
常见现象是 reflect.Value.FieldByName("name") 返回 IsValid() == false，哪怕结构体里明明有 name string `db:"user_name"`。根本原因是 Go 反射只能访问导出字段（首字母大写），小写字段无论加什么 tag 都拿不到。
- 必须把字段名改成大写：
UserName string `db:"user_name"`，而不是userName或name - 如果 legacy 代码不能改字段名，就得放弃
FieldByName，改用reflect.TypeOf(v).NumField()全量遍历，再逐个比对field.Tag.Get("db")是否匹配目标列名 - 别在循环里反复调
reflect.Value.FieldByName—— 它不缓存，每次都是线性查找，性能差还容易漏
nil 指针字段导致 panic: nil pointer dereference
结构体字段是 *string 或 *int64 类型，且值为 nil 时，直接调 v.Interface() 就崩。这不是 bug，是反射行为的必然结果。
- 必须先判断：
if v.Kind() == reflect.Ptr && v.IsNil() { continue }，跳过该字段或按IS NULL处理 -
v.IsValid()对 nil 指针也返回 true，不能用来代替v.IsNil() - 如果字段类型是
interface{}，得再套一层v.Elem()才能安全取值，否则v.Interface()可能返回空interface{}而不是底层值
IN 子句占位符数量和参数不匹配
传入 []int{1,2,3} 却只绑了一个 ?，执行时报 sql: expected 3 arguments, got 1。SQL 的 IN 不接受单个占位符展开，必须动态生成等长的 ?, ?, ?。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 对每个
IN条件，先用v.Len()算长度，再用strings.Repeat(", ", n-1)拼占位符串 - 参数切片必须同步构造：
make([]interface{}, v.Len())，然后逐个args[i] = v.Index(i).Interface() - 绝对不要用
fmt.Sprintf("IN (%s)", strings.Join(placeholders, ","))把占位符字符串拼进 SQL —— 这等于把?当字面量，数据库根本不会识别为参数
反射生成的 SQL 字符串喂给 database/sql 直接报错
比如拼出 "SELECT * FROM users WHERE name = :name"，再传给 db.Query，会报 sql: expected 0 arguments, got 1。因为原生驱动只认 ? 位置参数，不认识 :name 这种命名参数。
- 选
database/sql就老老实实全用?，参数用[]interface{}顺序传；选sqlx就全程用 struct 或 map，别混用 - 别在反射阶段生成带命名占位符的 SQL，再试图“降级”喂给原生驱动 —— 占位符不会被解析，变成死字符串
- 表名、字段名这类不能参数化的部分，必须白名单校验，不能靠反射自动读出来就往 SQL 里塞
最常被忽略的是：反射只负责“读结构体元信息”，它不理解业务语义。哪个字段该忽略、NULL 怎么写、时间要不要格式化——这些都得你在反射外显式控制。靠 reflect.Value.Interface() 直接塞进 SQL 字符串，等于把类型安全全交给了运气。
