必须白名单校验字段名并显式指定ASC/DESC方向，用数组传参如sort[]=name:asc&sort[]=updated_at:desc，服务端解析为有序列表，末尾加主键确保排序唯一性。
点击表头触发多字段排序时，ORDER BY 语句怎么拼才安全
直接拼接用户传来的字段名进 order by 是最常见也最危险的做法——sql 注入风险极高，且字段不存在时直接报错。必须做白名单校验，不能靠正则或黑名单过滤。
- 只允许前端传入预定义的字段别名（如
name、created_at、status），后端映射到真实列名和排序方向 - 排序方向（
ASC/DESC）必须显式指定，不能依赖默认值；多个字段排序时，每个字段都应有独立方向控制 - 避免用字符串拼接生成
ORDER BY name ASC, created_at DESC，改用参数化构造逻辑：先解析请求参数，再从白名单中查出对应列名+方向，最后 join 成字符串
前端点击表头多次切换时，sort 参数该怎么设计
单击升序、再单击降序、第三次清空——这个交互背后需要服务端能识别“当前字段是否已在排序列表中”，以及它的顺序位置。靠一个扁平的 sort=name:desc 不够用，容易丢掉多字段优先级。
- 推荐用数组形式传参，例如
sort[]=name:asc&sort[]=updated_at:desc，后端解析为有序列表 - 前端维护一个排序栈（stack），每次点击某列时：若该列不在栈中 → 推入并设为
asc；若已在栈中 → 弹出后再推入，方向取反；若栈顶是它 → 弹出清空 - 服务端收到空数组或无
sort参数时，应使用默认排序（如id DESC），而不是不加ORDER BY——否则分页结果不稳定
ORDER BY 多字段组合对索引失效的典型表现
即使你写了 ORDER BY a ASC, b DESC, c ASC，如果数据库没建对复合索引，查询可能全表扫描。MySQL 8.0+ 支持降序索引，但老版本会把 DESC 当作不匹配索引方向处理。
- 检查执行计划时重点看
key和Extra字段：出现Using filesort就说明没走索引排序 - 复合索引顺序必须严格匹配
ORDER BY字段顺序，且方向一致（旧版 MySQL 要求全是ASC或省略） - 如果业务常查
status = ? ORDER BY created_at DESC，索引应建为(status, created_at)，而非单独created_at
分页 + 多字段排序时，LIMIT OFFSET 的隐性陷阱
当排序字段存在重复值（比如多个记录 created_at 相同），OFFSET 分页会出现漏数据或重复数据——因为数据库内部排序不稳定，两次查询同一 OFFSET 可能返回不同行。
- 解决方法不是换
cursor-based pagination，而是让排序唯一：在多字段排序末尾加上主键，例如ORDER BY status ASC, created_at DESC, id DESC - 不要省略主键部分，哪怕你觉得“不会重复”——只要没
UNIQUE约束，就不能信 - 如果用
WHERE created_at 做游标分页，也要确保排序字段组合能支撑游标条件的单调性，否则跳页不准
