在聚合管道末尾添加一个 `$sort` 阶段，是对聚合结果进行排序最原生、最可控的方式，没有之一。你可能会认为这是“额外操作”，但它本身就是聚合框架内自带的排序机制，直接写在管道中即可。另一个常见的误区是：有人尝试用 `find().sort()` 对 `aggregate()` 的结果再排序——这基本行不通，因为 `aggregate()` 返回的是游标（cursor）而非数组，而 `find().sort()` 是查询级语法，只能作用于原始文档，无法叠加在聚合游标上。这样写要么报 `TypeError: result.sort is not a function`（在 Node.js 驱动中很常见），要么在某些旧驱动中静默失效，结果根本不排序。

**直接结论**：在聚合管道末尾加 `$sort` 阶段，就是对聚合后数据做二次排序的正确且唯一推荐方式。它不是“额外操作”，而是聚合框架内原生、可控、可组合的排序机制。 ### 为什么不能用 find().sort() 对 aggregate() 结果再排序 `aggregate()` 返回的是游标，不是数组；`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` 或没建索引，就可能让线上排序结果变得不可预测。