动态排序列+分页在gorm中必须用白名单校验和预定义映射，禁止字符串拼接c.query("sort")，否则必然导致sql注入、字段不存在或类型不匹配等错误。
动态排序列 + 分页在 GORM 中不能靠字符串拼接字段名实现，必须用 Order 配合白名单校验和预定义映射；否则 SQL 注入、字段不存在、类型不匹配都会直接 panic 或返回错乱结果。
为什么不能直接用 c.Query("sort") 拼进 Order()
常见错误是把前端传的 sort=created_at DESC 直接塞进 db.Order(sort).Find()。GORM 不做任何 SQL 转义，sort 里混入 id ASC; DROP TABLE users 这类内容会原样进 SQL —— 不是“可能被注入”，而是“必然被注入”。更隐蔽的问题是：字段名拼错（如 create_at）、类型不匹配（对 TEXT 字段用 DESC 无意义）、或没索引导致慢查询，GORM 全部静默放过，只在数据库报错时才暴露。
- MySQL 会报
Unknown column 'xxx' in 'order clause'，但 Go 层err可能为nil（因 GORM 把它当查询结果空处理） - PostgreSQL 对非法排序字段更严格，直接
panic: pq: column "xxx" does not exist - 即使字段存在，
Order("status ASC, name DESC")这种多字段写法若没提前验证组合合法性，容易漏掉二级排序导致分页重复
安全做法：排序字段白名单 + 显式方向控制
前端只传字段标识符（如 sort_by=id）和方向（sort_dir=desc），后端查白名单映射，再拼 Order。不要接受原始 SQL 片段。
- 定义白名单映射：
var sortMap = map[string]string{"id": "id", "name": "name", "created_at": "created_at", "updated_at": "updated_at"} - 方向只认
"asc"或"desc"，其他值强制 fallback 到"asc" - 组合时用
fmt.Sprintf("%s %s", sortMap[sortBy], dir)，再传给db.Order() - 如果允许复合排序（如
created_at DESC, id DESC），白名单里存完整字符串："recent": "created_at DESC, id DESC"，而非现场拼接
前端必须配合的三个约束
动态排序不是后端单方面的事，前端 URL 参数设计直接影响安全性与可维护性。
-
sort_by和sort_dir必须是两个独立参数，不能合并成sort=created_at:desc—— 冒号分割增加解析负担，且易被误截断 - 默认排序必须明确写死（如
sort_by=id&sort_dir=asc），不能让后端“自动选”，否则首次加载和刷新行为不一致 - 翻页时，
sort_by和sort_dir必须透传，不能只传page和page_size—— 否则用户切完排序再翻页，会回到默认排序，体验断裂
游标分页下动态排序的特殊处理
一旦启用游标分页（WHERE id > ? ORDER BY id LIMIT 20），排序字段就不再是可选项，而是查询逻辑的一部分。此时动态切换排序列等于重写整个查询模型。
- 支持多排序字段的游标分页，必须为每个字段组合预建索引，例如：
(created_at, id)和(name, id)，否则WHERE name > ? ORDER BY name会全表扫描 - 不能在同一次请求中既换排序字段又用游标 —— 游标值（如上一页最后的
id）只对当前排序有效，换字段后WHERE created_at > ?的游标无法复用id - 真实业务中，建议将“排序方式”作为独立筛选维度（类似 Tab 切换），每次切换都重置游标（
cursor=空），避免跨排序上下文的游标污染
最常被忽略的一点：排序字段的索引必须覆盖 WHERE 条件 + ORDER BY 字段。比如查询带 WHERE status = ? 又按 created_at DESC 排序，光有 created_at 索引没用，得建联合索引 (status, created_at)，否则 ORDER BY 仍会触发 filesort。
