空值字段不该参与sql构建，应通过指针区分“未提供”与“明确值”，用strings.builder拼接where条件，order by和limit单独处理，字段映射需显式声明避免反射错误。
拼接 WHERE 条件时，空值字段不该参与 SQL 构建
多字段联合查询最常踩的坑是：把 nil 或空字符串当有效条件拼进 WHERE，导致查不到数据或 SQL 报错。比如用户传了 name = ""、status = 0（但 0 是合法状态），这时不能一概过滤掉 0，而要区分「未提供」和「明确为 0」。
推荐用结构体字段加指针或自定义类型标记是否设置：
type UserFilter struct {
Name *string `json:"name,omitempty"`
Status *int `json:"status,omitempty"`
Age *int `json:"age_gte,omitempty"`
}
拼接时只处理非 nil 字段：
-
if f.Name != nil && *f.Name != ""→ 加name = ? -
if f.Status != nil→ 加status = ?（因为 0 是有效值） -
if f.Age != nil→ 加age >= ?
用 strings.Builder 拼接比 fmt.Sprintf 快且内存友好
高频查询场景下，反复用 fmt.Sprintf 拼 SQL 会频繁分配小字符串，GC 压力明显。实测 10 万次拼接，strings.Builder 耗时约 fmt.Sprintf 的 1/3，且对象复用率高。
注意点：
- 每次使用前调用
b.Reset()，避免残留旧内容 - 条件之间用
AND连接，开头不加WHERE，最后统一判断是否需要补 - 参数用
?占位，别硬编码值（防注入+兼容不同驱动）
示例片段：
b := &strings.Builder{}
b.WriteString("SELECT * FROM users WHERE 1=1")
if name != nil {
b.WriteString(" AND name = ?")
}
if status != nil {
b.WriteString(" AND status = ?")
}
ORDER BY 和 LIMIT 要单独处理，别混在 WHERE 拼接里
排序和分页逻辑与过滤条件本质不同：WHERE 是可选的布尔表达式，ORDER BY 和 LIMIT 是固定语法位置，且可能被客户端强制要求（如必须按 created_at DESC）。混在一起拼容易漏空格、错顺序，也难做校验。
建议拆成三段：
- WHERE 部分：用
strings.Builder动态生成 - ORDER BY 部分：白名单校验字段名 + 方向（
ASC/DESC），避免注入 - LIMIT 部分：只接受正整数，超范围截断（如 > 1000 则设为 1000）
拼接顺序固定为：SELECT ... FROM ... WHERE ... ORDER BY ... LIMIT ...
字段名映射要显式声明，别靠反射自动转 snake_case
Go 结构体字段名通常是 CreatedAt，但数据库列名是 created_at。用反射自动转下划线看似省事，但实际问题很多：
- 字段名含缩写（如
HTTPCode→h_t_t_p_code错误） - 部分字段不需要映射（如
ID对应id，但UserID应该对应user_id） - 无法区分同名不同义字段（如两个结构体都有
Name，但库表列名不同）
正确做法是定义映射表：
var userFieldMap = map[string]string{
"Name": "name",
"Status": "status",
"CreatedAt":"created_at",
}
拼接时查表取列名，没命中的字段直接跳过或报错，不 fallback 到反射。
复杂点在于字段组合爆炸——不同接口查不同表，每张表都要维护一份映射。最容易被忽略的是：没同步更新映射表导致字段查不到却无报错，静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
