gorm多字段排序需显式指定每个字段方向，不可依赖默认asc；多次order()调用会叠加而非覆盖；游标分页时多字段排序须确保组合值唯一。
多字段排序必须显式控制每个字段的方向
GORM 的 Order() 不支持像 Pandas 那样用单个布尔值统一控制所有字段方向。它接收的是原始 SQL 片段，所以升降序必须为每个字段单独指定，例如 "created_at DESC, name ASC, id DESC"。常见错误是传入 "created_at,name,id DESC"——这会让前两个字段默认按 ASC 排，且语法上容易漏掉逗号或空格，导致 SQL 解析失败。
实操建议：
- 不要拼接字符串时依赖“默认 ASC”，始终显式写出
ASC或DESC - 字段名和方向都要白名单校验，比如
validFields = map[string]bool{"created_at": true, "name": true, "id": true}，validDirs = map[string]bool{"ASC": true, "DESC": true} - 多个字段排序时，用
strings.Join([]string{...}, ", ")组合，比手写字符串更安全
Order() 多次调用是叠加，不是覆盖
调用多次 Order() 会追加到 ORDER BY 子句末尾，而不是替换。例如：db.Order("created_at DESC").Order("name ASC") 生成的 SQL 是 ORDER BY created_at DESC, name ASC。这看似方便，但容易误以为后一次调用会“重置”前面的排序逻辑。
常见错误现象：
- 在封装分页函数时，重复调用
Order()导致 SQL 中出现冗余字段，如ORDER BY id ASC, created_at DESC, name ASC，而实际只想按后两者排 - 中间件或钩子中悄悄调用了
Order()，业务层没意识到排序逻辑已被污染
建议：全局统一排序入口，避免分散调用；若需动态组合，用一个变量收集排序片段，最后一次性传给 Order()。
游标分页下多字段排序必须保证唯一性
当用基于主键/时间戳的游标分页（如 WHERE created_at ）时，多字段排序的字段组合必须能唯一确定一行。否则，相同 <code>created_at 值下，id 顺序不稳，会导致跳行或重复。
实操要点：
- 优先用主键（如
id）作为最右排序字段，确保最终顺序可重现 - 避免只按非唯一字段排序，例如
ORDER BY status, created_at—— 大量status = 'pending'时无法稳定分页 - 如果业务上确实需要按复合业务字段排序（如
priority, updated_at），务必在数据库加联合索引，并确认该组合在当前数据分布下足够离散
排序字段没索引时，Order() 就是性能瓶颈信号
Order() 本身不耗资源，但它触发的排序动作会强制数据库走 filesort（MySQL）或额外 sort node（PostgreSQL）。当排序字段无索引、又带大偏移（OFFSET 10000）时，查询可能从毫秒级升到秒级甚至超时。
判断依据：
- EXPLAIN 显示
Using filesort或Sort节点出现在执行计划顶部 - 慢日志里反复出现含
ORDER BY的长耗时查询 - 同一查询加索引前后响应时间差 10 倍以上
注意：GORM 不会自动帮你建索引，Order("price DESC") 写得再顺，没在 price 列上建索引，就是硬扛全表扫描。
