scopes是解决多重条件组合问题的唯一靠谱方案：它将各条件逻辑封装为独立函数，调用顺序无关且可复用，自动处理空值、括号和语义分组，避免手写where链导致的sql错误。
多重条件组合时，Where链必须用Scopes封装
直接在控制器里堆 Where、Or、Not 容易出错：条件顺序错乱、括号缺失、空值没跳过，最终 SQL 语义和预期不一致。比如想表达“状态是 active 或 pending，且 name 不为空，且 created_at 在范围内”，手写容易漏括号或把 Or 写成并列而非分组。
Scopes 是唯一靠谱的解法——它把每个条件逻辑封装成独立函数，调用时顺序无关，还能复用：
-
StatusInScope([]string{"active", "pending"})内部用Where("status IN ?", statuses)，自动跳过空切片 -
NameNotBlankScope()只在name != ""时才加Where("name != ''") -
TimeRangeScope(start, end)用Where("created_at >= ? AND created_at ，避免 <code>Or污染主逻辑
所有 Scope 函数统一接收 *gorm.DB 并返回新实例，组合起来像 db.Scopes(StatusInScope(...)).Scopes(NameNotBlankScope()).Order("id DESC")，可读性、可测性、可维护性全在线。
分页前必须先冻结 Where 条件，再单独 Count
很多人写 db.Where(...).Or(...).Not(...).Count(&total)，结果 total 是错的——GORM 的 Count 会复用前面链上所有 Where、Limit、Offset，但你根本没调 Limit，所以看似只查总数，其实已经带了复杂条件；更糟的是，如果某个 Scope 里悄悄改了 Limit（比如调试时加的），Count 就彻底不可信。
正确做法是用 Session 隔离上下文：
- 先构造带全部条件的
baseDB := db.Scopes(...).Scopes(...) - 总数查：
baseDB.Session(&gorm.Session{NewDB: true}).Model(&User{}).Count(&total) - 列表查：
baseDB.Offset((page-1)*size).Limit(size).Find(&users)
注意：不能用 baseDB.Count()，也不能用 baseDB.Limit().Offset().Count()——前者污染，后者算的是截断后数量。
Or/Not 嵌套多层时，Order BY 必须带唯一二级字段
复杂条件常导致排序字段重复值变多。比如按 status 和 priority 排序，但多个记录 status = 'pending' 且 priority = 5，这时只写 Order("status DESC, priority DESC")，MySQL 返回顺序不保证稳定，翻页时同一条记录可能出现在两页里，或者直接消失。
解决方法只有一个：强制加主键或带索引的唯一字段作兜底：
- ✅ 推荐：
Order("status DESC, priority DESC, id ASC")——id有索引，且绝对唯一 - ⚠️ 慎用：
Order("created_at DESC, id DESC")—— 如果created_at是秒级精度且并发高，仍可能撞时间 - ❌ 禁止：
Order("status, priority")不加任何唯一字段，等于裸奔
这个规则和条件复杂度无关，但条件越复杂、数据越稀疏，排序不确定性越明显，别心存侥幸。
大数据量下，别硬扛 Offset 分页
当 WHERE 条件本身就很重（比如 JOIN 三张表 + 多个 OR + LIKE 模糊匹配），再叠上 OFFSET 10000，MySQL 得先执行完整条件扫描，再丢弃前一万行——响应从 50ms 拉到 2s+ 是常态，而且无法靠 GORM 优化。
此时该换思路：
- 前端传
last_id而非page，SQL 改成WHERE id > ? AND ... ORDER BY id LIMIT 20 - 如果业务允许跳页（比如不支持“跳到第 87 页”），游标分页几乎零成本升级
- 如果必须支持跳页，且条件中含
OR，优先给高频组合字段建联合索引，例如(status, priority, id)，让 WHERE + ORDER BY 能走同一索引
Offset 分页不是写法问题，是数据模型和访问模式问题。条件越复杂，越早该放弃页码制。
