ORDER BY 必须显式声明，否则数据库不保证返回顺序；导出需剥离分页参数、避免前端二次排序、统一编码与转义规则。
ORDER BY 必须显式声明，否则数据库不保证返回顺序
数据库查询结果默认无序，哪怕表里数据按某字段插入，也不代表 select 不加 order by 就会按插入顺序或索引顺序返回。导出脚本和界面查询如果一个写了 order by、一个没写，立刻出现顺序不一致。
常见错误现象：SELECT * FROM orders 在页面看到的是按时间倒序，导出却是随机乱序；或者导出 CSV 第一行是最新订单，第二行却是半年前的——其实只是碰巧缓存/执行计划变了。
- 所有需要稳定顺序的查询，
ORDER BY是硬性要求，不能依赖“看起来对” - 复合排序要写全，比如
ORDER BY status ASC, created_at DESC，漏掉ASC/DESC可能导致和前端预期相反 - 注意 NULL 值排序行为：不同数据库默认把
NULL排最前或最后，MySQL 8.0+ 和 PostgreSQL 支持NULLS FIRST/LAST，但旧版本得用COALESCE或条件表达式兜底
导出逻辑复用界面查询 SQL 时，别漏掉 LIMIT/OFFSET
很多后端导出接口为了“复用代码”，直接拿分页查询的 SQL 去执行，但忘了删掉 LIMIT 和 OFFSET。结果导出只有一百条，还和第一页显示一样——这不是顺序问题，是数据就不全。
使用场景：管理后台点击“导出全部”，后端却只查了 SELECT ... LIMIT 100 OFFSET 0。
- 导出必须剥离分页参数，不能靠“前端传个 flag 就自动去掉 LIMIT”——容易漏判或误判
- 更稳妥的做法是拆成两个 SQL：一个带分页用于界面，一个不带分页用于导出，共用核心 WHERE 和 ORDER BY 部分
- 如果真要动态拼接，检查
LIMIT是否存在比正则替换更可靠；例如用sql.replace(/LIMIT\s+\d+(\s+OFFSET\s+\d+)?/i, '')容易误伤字段名含 LIMIT 的注释或字符串
前端 JS 排序和后端排序混用导致二次错乱
有些前端在拿到数据后，又用 Array.prototype.sort() 按某个字段再排一次，而这个字段后端其实已经排过了。一旦前后端排序规则不一致（比如大小写、中文拼音 vs Unicode 码点），顺序就彻底不可控。
错误示例：后端返回 ORDER BY name，前端又执行 data.sort((a, b) => a.name.localeCompare(b.name))，结果 MySQL 默认 utf8mb4_general_ci 和 JS localeCompare 的排序结果可能差几个位置。
- 明确分工：排序由后端统一做，前端只负责渲染，不重排
- 如果必须前端排序（如切换列头），确保排序逻辑可逆且与后端一致；比如都用
Intl.Collator并指定相同 locale 和 sensitivity - 警惕时间字段：后端返回的
created_at是字符串还是时间戳？JSsort()直接比字符串会出错，得先new Date()解析
导出文件编码或 BOM 头干扰 Excel 自动识别列顺序
导出 CSV 时用了 UTF-8 with BOM，Excel 打开后第一列显示乱码，用户手动调整列宽或排序后保存，再导入系统——这时候顺序早已不是原始查询顺序，而是 Excel 重排后的。
这不是程序逻辑问题，但会导致“导出和界面不一致”的投诉。
- 导出 CSV 一律用纯 UTF-8（无 BOM），避免 Excel 误判编码导致列偏移
- 字段名含逗号、换行、双引号时，必须按 RFC 4180 规则转义，否则 Excel 解析错位，后续所有排序都失效
- 如果导出 Excel（.xlsx），用
xlsx库而非字符串拼接，它天然保持行列顺序；别用csv2excel类工具二次转换
导出顺序不一致，八成不是算法问题，而是某一层悄悄绕过了排序约定——要么 SQL 少写了 ORDER BY，要么导出时截了段，要么前端又搅了一手，要么文件本身被 Excel 搞变形了。盯住这四点，比调优查询语句更管用。
