$sort阶段是聚合管道中实现全局排序的唯一标准方式，需严格按字段顺序执行、加入_id确保稳定性、配合匹配索引避免oom，并支持collation处理大小写与数字排序。
$sort 阶段本身就是聚合管道中实现全局排序的唯一标准方式——它会对整个输入文档流做全量排序，不是局部、不是分片、不是采样，是真正意义上的全局。
但“全局”不等于“稳定”或“高效”，实际用起来有几个关键点必须提前确认清楚，否则结果可能出人意料。
为什么 $sort 看似简单却容易返回乱序？
因为 MongoDB 的 $sort 不是稳定排序（stable sort）。当多个文档在排序字段上值相等时，它们的相对顺序不保证与输入一致。
- 比如按
status: 1排序，所有status: "pending"的文档会聚在一起，但彼此顺序随机 - 这在分页、导出、前端渲染时可能造成“翻页重复”或“视觉跳动”
- 解决办法：强制加入一个唯一字段，最常用的是
_id
正确写法示例：
[{ $sort: { status: 1, _id: 1 } }]
这样即使 status 相同，_id 也能提供确定性顺序。
$sort 多字段排序的优先级和字段顺序怎么理解？
多字段排序严格按对象键的书写顺序执行，从左到右逐级细化。
-
{ age: -1, name: 1 }表示：先按age降序；age相同的再按name升序 - 字段名不能重复，否则报错：
"Sort key element cannot be duplicated" - 最多支持 32 个排序字段，超限会直接失败
- 注意：字段名必须是字符串字面量，不能是变量拼接（除非用 JS 动态构建 pipeline）
大数据量下 $sort 为什么会卡住或 OOM？
$sort 是阻塞阶段（blocking stage），必须把上游所有文档全部拉入内存才能开始排序。这对性能和资源消耗影响极大。
- 没索引时，10 万条文档排序可能吃掉几百 MB 内存，且无法并行
- 如果排序字段没建索引，MongoDB 无法利用索引顺序，只能走内存排序
- 解决方案不是“优化
$sort”，而是“让$sort前就能用上索引”
建索引命令示例（与 $sort 字段和方向严格一致）：
db.orders.createIndex({ status: 1, amount: -1 })
只要聚合管道中 $sort 出现在该索引能覆盖的位置（且前面没有 $skip/$limit 打断），MongoDB 就可能直接用索引完成排序，避免内存加载。
需要不区分大小写或按数字语义排序怎么办？
默认的二进制排序（BSON 比较规则）对字符串是区分大小写的，对数字字符串（如 "10", "2"）会当成文本比，导致 "10" 。
- 解决大小写问题：用
collation指定locale，例如{ locale: "en", strength: 2 } - 解决数字字符串排序：必须开启
numericordering: true，否则"9" > "10"会成立 - collation 必须加在整个聚合操作上（不是单个
$sort阶段），例如：
collection.aggregate(pipeline, { collation: { locale: "en", numericordering: true } })
注意：collation 会影响索引匹配——带 collation 的查询，必须用同样 collation 的索引才生效。
$sort”，而是“怎么让 $sort 不拖垮整个聚合”。字段是否唯一、索引是否存在、collation 是否匹配、内存是否够用——这些细节一旦漏掉一个，就可能在线上突然慢十倍甚至失败。
