GORM动态多重排序+分页必须用字段白名单校验、显式Order链组合、独立COUNT查询，否则必现漏数据、重复、慢查询；禁用字符串拼接Order、禁用逗号复合Order、禁用共用DB实例查总数。
动态多重排序 + 分页在 GORM 中不能靠“拼字符串”或“反射塞 Order()”糊弄过去，必须拆解为确定性字段白名单 + 显式组合顺序 + 独立 COUNT 查询，否则漏数据、重复、慢查询三连击避无可避。
Order 字段必须来自预设白名单，禁止直接透传前端字段名
前端传 sort=created_at,desc 或 sort=status,asc&sort=id,desc 很常见，但直接用 db.Order(fmt.Sprintf("%s %s", field, dir)) 是高危操作：SQL 注入风险、字段不存在时 panic、排序不稳定（如只按 status 排会因值重复导致分页错乱）。
- 定义安全字段白名单，例如：
map[string]string{"id": "id", "created_at": "created_at", "updated_at": "updated_at", "name": "name"}，不在其中的字段一律忽略或报 400 - 方向参数也需校验，只接受
"asc"和"desc"，大小写统一转小写再比对 - 多重排序必须显式拼接，例如：
db.Order("created_at DESC").Order("id DESC")，不能写成db.Order("created_at DESC, id DESC")—— GORM v2 对逗号分隔的复合 Order 支持不一致，某些版本会忽略第二段 - 时间字段务必补主键兜底：
Order("created_at DESC").Order("id DESC")比单用created_at更稳，避免毫秒级重复导致排序漂移
分页参数校验必须在 Offset 计算前完成，且 page_size 要硬截断
Offset((page - 1) * pageSize) 这行代码看着标准，实则埋着三个雷：page 为 0 或负数、pageSize 是非数字字符串、pageSize 过大触发数据库性能雪崩。
- 用
strconv.Atoi前先判空：if p.Page == "" { p.Page = "1" }，空字符串直接转 int 会 panic - page 小于等于 0 时强制设为 1，不接受语义模糊的 “第 0 页”
- pageSize 必须限制上限（如 100），超限不报错也不放行，而是
pageSize = min(pageSize, 100)，防恶意刷库 - 别依赖
c.ShouldBindQuery(&p)自动容错——它对非法数字只返回 error，你得显式检查并终止流程，不能忽略
Count 查询必须隔离上下文，别和 Find 共用同一个 *gorm.DB 实例
写 db.Where("status = ?", "active").Limit(20).Offset(40).Count(&total) 查出来的 total 永远 ≤ 20。GORM 的 Count() 会继承链上所有 Limit 和 Offset，这不是 bug，是设计如此。
- 正确做法是拆成两个独立构建：
query := db.Where("status = ?", "active")，再分别调用query.Count(&total)和query.Order(...).Limit(...).Offset(...).Find(&list) - 如果 WHERE 条件含
Joins或复杂子查询，Count()可能比主查询还慢，此时应手写子查询 SQL：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN ... WHERE ...) t").Scan(&total) - 事务中慎用两次查询：Count 和 Find 之间若发生 INSERT/DELETE，总数和当前页数据就对不上——业务若容忍，可接受；若要求强一致，得加锁或改用游标
大数据量下必须放弃 Offset，游标分页不是优化项而是保命线
当表行数超 10 万，Offset(50000) 在 MySQL 上实际要扫描并丢弃前 5 万行，响应时间从 20ms 拉到 1.5s+。这不是 GORM 层能绕开的问题，是查询模型缺陷。
- 游标分页依赖上一页最后一条记录的排序字段值，例如首次请求
ORDER BY created_at DESC, id DESC LIMIT 20，取回users[len(users)-1].CreatedAt和users[len(users)-1].ID作为下一页的last_created_at和last_id - 下一页 SQL 为：
WHERE (created_at, id) —— 注意括号内是元组比较，需数据库支持（MySQL 8.0+、PostgreSQL 均支持） - 复合索引必须覆盖排序字段：
INDEX idx_created_at_id (created_at, id)，否则游标查询也会变慢 - 别在游标分页里混用
Preload，关联数据应分两步：先查主表 ID 列表，再用IN批量加载，避免 N+1 或 JOIN 导致游标逻辑失效
多重排序字段的组合顺序、索引覆盖、COUNT 隔离、游标边界处理——这些点一旦漏掉一个，分页接口就可能在高并发或大数据量下 quietly 失效。没有银弹，只有每个环节都卡死校验和约束。
