在聚合管道末尾加 $sort 阶段是对聚合结果排序的正确且唯一推荐方式，它原生可控、可组合；不能用 find().sort() 对 aggregate() 结果再排序，因 aggregate() 返回游标，不支持查询级 sort，否则报错或静默失效。
直接结论：在聚合管道末尾加 $sort 阶段，就是对聚合后数据做二次排序的正确且唯一推荐方式。它不是“额外操作”，而是聚合框架内原生、可控、可组合的排序机制。
为什么不能用 find().sort() 对 aggregate() 结果再排序
aggregate() 返回的是一个游标（cursor），不是数组；find().sort() 是查询级语法，只作用于未进入聚合管道的原始文档。对 aggregate() 的结果调用 .sort() 会报错或被忽略——MongoDB 不允许在聚合游标上叠加查询级 sort。
- 常见错误现象：
TypeError: result.sort is not a function（Node.js 驱动）或静默失效（某些旧驱动） - 真正有效的排序必须发生在聚合管道内部，且通常放在最后（除非你后续还要 $limit / $skip）
- 如果你看到代码里写了
db.col.aggregate([...]).sort(...)，那基本是误用或过时写法
$sort 放在管道末尾的典型位置和写法
绝大多数场景下，$sort 应该是倒数第二个或最后一个阶段——倒数第一用于纯排序，倒数第二用于排序后再 $limit 或 $skip 分页。
- 基础写法：
{$sort: {score: -1, createdAt: 1}}—— 先按 score 降序，相同 score 时按 createdAt 升序 - 多字段排序严格从左到右：字段顺序即优先级顺序，不支持“先整体按 A 排，再局部按 B 排”这种逻辑外推
- 如果前面已有
$group，$sort操作的是 group 后的输出文档，字段名必须是 group 输出里的（比如_id或自定义的count字段） - 示例（统计后按数量降序）：
[{$group: {_id: "$status", total: {$sum: 1}}}, {$sort: {total: -1}}]
容易踩的坑：排序一致性与性能代价
$sort 是阻塞阶段，且默认不保证重复值下的稳定顺序——这常被忽略，但直接影响业务逻辑。
- 现象：两个文档
score都是 100，但每次查询返回顺序不同，前端列表“闪动” - 根本原因：MongoDB 不承诺对相同排序键的文档维持插入/存储顺序
- 解决办法：在
$sort中至少加入一个唯一字段，最稳妥的是_id，例如{$sort: {score: -1, _id: 1}} - 性能提醒：大数据集上
$sort可能吃光内存，触发allowDiskUse: true；务必为排序字段建索引（如db.col.createIndex({score: -1, _id: 1})）
真正麻烦的不是加不加 $sort，而是加在哪、按什么字段加、以及是否意识到它对一致性和资源的实际影响。管道末尾那个 {$sort: {...}} 看似简单，但漏掉 _id 或没建索引，就可能让线上排序结果变得不可预测。
