分页查询必须显式调用Order()，否则结果不可预测；应使用确定性排序如Order("created_at DESC, id DESC")，禁用Order("RAND()")和用户输入拼接，并优先采用游标分页应对动态排序场景。
Order() 必须显式调用，不能省略或依赖默认行为
没写 Order() 的分页查询，结果不可预测——这不是 GORM 的 bug，是 SQL 标准决定的。MySQL 和 PostgreSQL 对无序查询不保证行序，哪怕表静态、无并发写入，同一条 Limit()/Offset() 查询多次执行也可能返回不同记录。
常见错误现象：db.Limit(10).Offset(100).Find(&users) 返回空 slice 但 err == nil；翻页时某条记录突然消失或重复出现。
- 必须用
Order("id ASC")或Order("created_at DESC, id DESC")这类带确定性顺序的组合 - 避免单用
Order("status ASC")——值重复太多，数据库内部排序不稳定 - 时间字段慎用
Order("created_at DESC")：高并发下毫秒级重复常见，补上, id DESC更稳妥 -
Order("RAND()")不能用于分页，性能差且无法支持下一页续查
动态排序字段需白名单校验，禁止拼接用户输入
前端传 sort=created_at、order=desc 很常见，但直接拼进 Order(fmt.Sprintf("%s %s", sort, order)) 是严重安全漏洞，可能引发 SQL 注入或语法错误。
实操建议：
- 定义允许的排序字段白名单：
validSortFields := map[string]bool{"id": true, "created_at": true, "updated_at": true, "name": true} - 只接受预设值：
order参数只允许"asc"或"desc"，其他一律 fallback 到"asc" - 组合时用字符串拼接前先校验：
if !validSortFields[sort] { sort = "id" } - 不要用
db.Order("?" + " " + order)——Order()不支持参数占位符，? 会被当作文本字面量
游标分页比 Offset 分页更适合动态排序场景
当排序规则可变（比如用户切“按销量”“按评分”“按时间”），又要求数据稳定、性能可控，Offset 分页基本不可用。因为每次排序字段变化，原有 OFFSET 偏移量就失效，且高偏移下性能断崖式下降。
游标分页绕过这个问题：它不依赖“第几页”，而是基于上一页最后一条记录的排序字段值继续查。
- 首次请求：用
Order("score DESC, id DESC")查前 20 条 - 后续请求：前端传
last_score=95.6&last_id=12345，后端生成WHERE score - 关键点：排序字段必须有联合索引（如
INDEX(score, id)），否则无法高效定位 - 注意：
ASC和DESC方向要反着写条件（比如ORDER BY name ASC对应WHERE name > ?）
Scopes 封装动态排序+分页时，Order 必须在 Scope 内部固定位置
用 Scopes 抽象分页逻辑很常见，但若把 Order() 放在分页 Scope 外面，极易被其他 Scope 覆盖或错序。GORM 链式调用中，Order() 必须出现在 Limit()/Offset() 之前，且不能被后续 Where() 等干扰。
正确做法是把排序和分页一起封装进一个 Scope：
func PaginateScope(page, pageSize int, sortField, sortOrder string) func(db *gorm.DB) *gorm.DB {
return func(db *gorm.DB) *gorm.DB {
// 先校验并标准化排序
if !validSortFields[sortField] {
sortField = "id"
}
if sortOrder != "desc" {
sortOrder = "asc"
}
db = db.Order(sortField + " " + sortOrder)
<pre class="brush:php;toolbar:false;"> // 再应用分页
return db.Offset((page - 1) * pageSize).Limit(pageSize)
}}
调用时：db.Scopes(PaginateScope(p.PageNum, p.PageSize, p.Sort, p.Order)).Find(&users)。这样能确保 Order() 永远在分页参数生效前执行，不会被其他条件覆盖。
真正容易被忽略的是：动态排序字段变更时，旧游标值（比如上一页最后的 created_at）对新排序（比如 score）完全无效，此时必须重置游标或强制跳转到第一页——这点在接口文档和前端交互里常被漏掉。
