Order() 必须校验字段名和方向以防SQL注入，仅允许白名单字段与asc/desc方向；调用顺序需Order在Limit/Offset前；多字段排序须拆分校验；外键排序需用Joins而非Preload；深分页前须确保排序字段有索引。
Order() 必须校验字段名和方向，否则就是SQL注入入口
Order() 接收的是原始 SQL 片段，不经过任何转义或参数化处理。传入 "name " + r.URL.Query().Get("order") 这类拼接，等于把用户输入直接喂给数据库解析器。
常见错误现象：前端传 sort=name&order=desc 能跑，但攻击者发 sort=id; DROP TABLE users-- 就可能触发注入；日志里只看到一条“查询失败”，根本看不出是 SQL 被篡改了。
安全做法只有两个硬性步骤：
- 定义白名单映射：
validSortFields := map[string]string{"name": "name", "created_at": "created_at", "price": "price"} - 方向只接受
"asc"或"desc"，其他值一律 fallback 到"asc" - 拼接用
fmt.Sprintf("%s %s", colName, orderDir)，再传给db.Order()
GORM 中 Order() 和 Limit()/Offset() 的调用顺序不能错
链式调用是“后写先执行”，但排序必须在分页前生效。否则 ORDER BY 作用在已被 LIMIT 截断的数据上，结果是每页内部有序、跨页完全乱序。
✅ 正确写法：db.Where("status = ?", "active").Order("created_at DESC").Limit(20).Offset(40)
❌ 错误写法：db.Where("status = ?", "active").Limit(20).Offset(40).Order("created_at DESC")
如果你封装了 Page() 方法，务必确认它内部是否已将 Order() 提前应用——没验证前，别默认它能保序。
多字段排序要拆开校验，不能直接信任逗号分隔字符串
用户传 sort_by="created_at,name"&order="desc,asc" 看似方便，但直接 db.Order(sort_by + " " + order) 会跳过字段合法性检查，且方向和字段数量不匹配时容易 panic 或静默失效。
正确做法是手动解析并逐个校验：
- 用
strings.Split(sort_by, ",")拆出字段名数组 - 对每个字段查白名单，非法字段直接跳过（或整体 fallback）
- 方向字符串也按逗号拆，长度不足时补默认值，超长则截断
- 最后用
strings.Join([]string{"created_at DESC", "name ASC"}, ", ")组合成完整子句
外键关联字段排序不能靠 Preload + Order，得用 Joins
像 User 关联 Role，想按 role.tier_level 排序，仅写 db.Preload("Role").Order("role.tier_level DESC") 是无效的——GORM 不会自动把 role. 映射到 JOIN 后的表别名，生成的 SQL 会报 “unknown column”。
必须显式 Joins() 并指定别名：
db.Joins("JOIN roles ON users.role_id = roles.id").
Order("roles.tier_level DESC").
Find(&users)
注意：如果用了软删除（gorm.DeletedAt），还要在 Joins 条件里加上 AND roles.deleted_at IS NULL，否则关联数据可能被意外过滤掉。
最易被忽略的一点：深分页（比如 OFFSET 10000）+ 无索引的排序字段，会让 Order() 从语法问题变成性能瓶颈。别只盯着怎么拼字符串，先看执行计划里有没有用上索引。
