Golang 中 reflect 动态构造带有参数的数据库查询对象

最稳的路径其实是用 reflect.New 构造结构体指针，再结合 db tag 来提取字段映射和值。v.Interface() 一调就 panic，最常见的原因是什么？十有八九是因为字段是 *string、*int64 这类指针类型，而且值是 nil。遇到这种情况，必须先判断 v.Kind() == reflect.Ptr && v.IsNil()，再决定怎么处理。单单靠 IsValid() 是不够的。

直接用 reflect.New 构造结构体指针，再通过 db tag 提取字段映射和值，这是构建带参查询对象最稳的路径。至于 map[string]interface{}，建议尽量不用——类型模糊，nil 处理但凡错一丁点，就会崩在 v.Interface() 上，非常麻烦。

为什么 v.Interface() 一调就 panic？

最常见的原因是字段是 *string、*int64 这类指针类型，而且值为 nil。此时 v.Kind() == reflect.Ptr 为 true，v.IsNil() 也为 true，但如果你直接调用 v.Interface()，它会直接触发 nil pointer dereference。

• 首先，别完全依赖 v.IsValid()——它对 nil 指针也返回 true，但后续取值仍然会崩。
• 正确的做法是：先判断 if v.Kind() == reflect.Ptr && v.IsNil()，再根据情况决定是跳过这个字段，还是生成 "col IS NULL" 这样的条件。
• 如果确实需要继续取值，必须先执行 v = v.Elem() 来解引用，接着检查它是否为 interface{} 类型，必要时再执行一次 v.Elem()。
• 特别值得一提的是，当字段是 interface{} 类型且底层是 *string 时，如果不额外解包，很可能会把空的 interface{} 当成有效值传出去，造成奇怪的 bug。

怎么安全提取非零字段用于 WHERE 条件？

核心问题不是“这个字段有没有值”，而是“它要不要参与 WHERE 条件”。空字符串、零值、nil，这三者的语义完全不同，不能一概而论。

• 在调用 v.Field(i).Interface() 之前，必须包裹在 if !IfZero(v.Field(i).Interface()) 判断里。而这个 IfZero 函数需要自己写完整，把 nil、""、0、false 以及它们的指针形式都覆盖到。
• db tag 的格式建议统一成 db:"name,eq" 或 db:"name,like*" 这样的形式。避免用逗号分隔太多语义，比如 db:"name,unique,ignore,auto" 这种，解析起来太容易出错。
• 遇到 like* 这类修饰符，不要在反射循环里直接拼 SQL 字符串。更好的做法是：先收集条件的元信息，包括字段名、操作符和原始值，最后统一生成 WHERE 片段和 []interface{} 参数。

如何从结构体生成参数化查询的列名 + 占位符 + 值切片？

这里有个关键原则：反射只负责生成列名和 ? 占位符，绝不参与值的拼接。所有值都必须通过 sql.Named 或 ? 绑定，确保参数化查询的安全性和正确性。

• 对于 INSERT 操作，收集所有非 ,auto 字段的列名和 ? 占位符，然后按顺序返回 []interface{} 值切片。
• 对于 UPDATE 操作，排除 ,pk 和 ,ignore 字段作为 SET 部分；而 ,pk 字段则用来生成 WHERE 条件，比如 WHERE id = ?。
• 当字段名和数据库列名不一致时，靠 db tag 映射是最轻量而且编译期就可查的方式，比运行时查 map 键名要可靠得多。
• 定义结构体时，要显式加上 tag，比如 Name *string `db:"user_name"`。反射时用 v.Type().Field(i).Tag.Get("db") 来提取。如果 tag 的值是 "-" 或者空字符串，就直接跳过这个字段。

说到底，真正难的不是拼出 SQL 字符串，而是让每个字段的“存在性”、“空值语义”和“绑定参数顺序”全部对齐。建议缓存 reflect.Type 和字段 tag 的解析结果，比如用 sync.Once 来实现。否则每次查询都重复切分字符串、判断有效性，性能会明显掉档——这一点在实际项目中非常关键。