结论：简单等值查询用filter，带运算符或组合条件必须用where；filter不支持双下划线语法，多条件需合并到单个where中，动态字段须白名单校验，空参数需前置判断。
Beego ORM 的 Where 和 Filter 怎么选
直接说结论：简单等值查询用 Filter，带运算符（>=、IN、LIKE）或组合条件必须用 Where。Beego 的 Filter 本质是字段名 + 值的严格匹配，不支持操作符；而 Where 接收原生 SQL 片段，更灵活但需手动防注入。
常见错误是把 Filter("age__gte", 18) 当成合法写法——它不会报错，但实际被忽略，因为 Filter 不识别双下划线语法（那是 Django 风格）。
-
Filter("status", "active")✅ 等价于WHERE status = 'active' -
Where("age >= ?", 18)✅ 支持参数化，安全 -
Where("name LIKE ?", "%john%")✅ 注意通配符要自己加 -
Filter("created__gt", "2024-01-01")❌ 无效，会被静默跳过
多条件 AND 查询怎么拼接
Beego ORM 没有链式调用，所有条件都得在一次 QueryTable 调用中完成。不能像 GORM 那样写 .Where(...).Where(...)，多次调用会覆盖前一个条件。
正确做法是把多个 Where 合并为一个字符串，用 AND 连接，并确保参数顺序和占位符一一对应：
qs := orm.QueryTable(&User{})
qs.Where("status = ? AND age >= ? AND created >= ?", "active", 18, "2024-01-01")
容易踩的坑：
- 混用
Filter和Where：后者会覆盖前者，例如Filter("status", "active").Where("age > 18")实际只执行了WHERE age > 18 - 参数类型不匹配：比如数据库字段是
INT，却传入字符串"18"，MySQL 可能隐式转换，但 PostgreSQL 会报错 - 时间格式没转成数据库能解析的格式，如传入 Go 的
time.Time值，需先调用t.Format("2006-01-02 15:04:05")
动态条件查询怎么避免 SQL 注入
用户输入的字段名、操作符不能直接拼进 Where 字符串。比如不能写 Where(userField + " = ?", userValue)，因为 userField 是不可信的。
安全做法是预先定义白名单，再做映射：
validFields := map[string]bool{"name": true, "email": true, "status": true}
validOps := map[string]bool{"=": true, ">=": true, "LIKE": true}
if !validFields[field] || !validOps[op] {
// 返回错误或忽略
}
qs.Where(field+" "+op+" ?", value)
更稳妥的方式是完全避开动态字段名，改用固定字段 + switch 分支处理不同条件逻辑，尤其适合搜索表单这类场景。
空值或可选参数怎么处理
前端传来的查询参数经常是可选的（比如“年龄最小值”可能为空），这时候不能无脑塞进 Where，否则会查出空结果。
推荐在构建 qs 前先收集有效条件，再一次性拼接：
var wheres []string
var params []interface{}
if name != "" {
wheres = append(wheres, "name LIKE ?")
params = append(params, "%"+name+"%")
}
if status != "" {
wheres = append(wheres, "status = ?")
params = append(params, status)
}
if len(wheres) > 0 {
qs.Where(strings.Join(wheres, " AND "), params...)
}
注意点：
- 不要用
Where("name LIKE ?", "%"+name+"%")直接拼接用户输入，万一name包含%或_会导致意料外的模糊匹配 - 如果所有参数都为空，就别调
Where，否则可能查出全表（取决于是否还有其他默认条件） - PostgreSQL 对空字符串和
NULL区分严格，WHERE name = ''和WHERE name IS NULL完全是两回事，别混淆
最麻烦的其实是日期范围查询里的边界处理——比如“创建时间在某天之内”，到底是 BETWEEN 还是 >= AND ，时区有没有对齐，这些细节一旦漏掉，查出来的数据就少了一整天。
