SetCond 不能替代 Filter 链式调用，因其直接覆盖而非追加条件；需显式构建 *orm.Condition 对象，混用会清空 Filter 条件；复杂嵌套逻辑（如 OR+AND）才适用，普通筛选应坚持 Filter。
SetCond 不能替代 Filter 链式调用
SetCond 是 QuerySeter 提供的底层条件组装接口，但它**不自动合并或追加条件**，而是直接覆盖已有条件。常见误用是以为它能像 GORM 那样累积条件：qs.SetCond(cond1).SetCond(cond2) 最终只生效 cond2。实际中，SetCond 适合一次性构造复杂嵌套逻辑（比如 OR + AND 混合），而不是逐步拼条件。
典型场景：需要 (status = 1 AND created__gte = '2024-01-01') OR (is_deleted = false) 这类结构时才值得动用 SetCond；普通多字段等值筛选，坚持用 Filter() 链式写法更安全、可读性更高。
Condition 对象必须显式构建，不能直接传 map
SetCond 接收的是 *orm.Condition 类型，不是 map 或 struct。你得手动用 orm.NewCondition() 初始化，再链式调用 And()、Or()、In() 等方法：
cond := orm.NewCondition()
cond = cond.And("status", 1).And("created__gte", "2024-01-01").Or("is_deleted", false)
qs := o.QueryTable("user").SetCond(cond)容易踩的坑：
-
And("age", 0)会把 age=0 当作有效条件执行，和Filter一样——空值/零值不会被跳过 -
Or()的括号层级靠方法调用顺序隐含，cond.And(...).Or(...)等价于(A AND B) OR C，想表达A AND (B OR C)必须拆成两个Condition再AndCond() - 字符串字段仍需手动 trim 判空，
cond.And("name", strings.TrimSpace(r.FormValue("name")))后还得检查是否为空字符串
SetCond 和 Filter 混用会丢失 Filter 条件
SetCond 和 Filter 属于两套独立条件机制。一旦调用了 SetCond，之前所有 Filter、Exclude 添加的条件都会被清空——这不是 bug，是设计如此。所以：
- 不要在
qs.Filter("a", 1).Filter("b", 2)后再写.SetCond(cond) - 如果部分条件固定、部分动态复杂，建议全部统一走
SetCond构建，避免混用 - 调试时可用
qs.GetCond()查看当前生效的Condition结构，但注意它返回的是指针，打印需解引用
Raw() 仍是 OR 多字段模糊匹配的最终解
即使用了 SetCond，也**无法生成 WHERE name LIKE ? OR title LIKE ? 这类语句**——因为 Condition 不支持 LIKE 操作符，也不处理通配符拼接。此时必须退到 Raw()：
kw := "%" + strings.TrimSpace(r.FormValue("q")) + "%"
o.Raw("SELECT * FROM user WHERE name LIKE ? OR title LIKE ?", kw, kw).QueryRows(&users)关键提醒：
- 绝不能用字符串拼接用户输入，
"%" + q + "%"只能在服务端做，且必须经strings.TrimSpace和长度限制 - 若还需 ORM 映射（如关联字段加载），先
Raw()查 ID 列表，再QueryTable("user").Filter("id__in", idList)二次查询 -
SetCond在这种场景下纯属绕路，增加理解成本且无收益
真正复杂的条件组合，往往不是语法问题，而是空值判断、字段类型隐式转换、SQL 注入边界这三块最容易漏掉。别迷信 SetCond 的“灵活性”，多数时候老老实实用好 Filter 链式调用 + 显式空值守卫，反而更稳。
