$limit的位置影响索引使用、内存占用和结果可重现性，会被优化器重排甚至与$sort合并以减少计算量；放$sort前会导致结果不完整且不稳定；加_id可解决排序歧义确保结果确定。
$limit 的位置直接影响查询是否走索引、内存占用大小，以及结果是否可重现——它不是简单“切掉后面文档”的黑盒操作，而是会被优化器主动挪动、甚至和 $sort 合并的阶段。
为什么 $limit 会被 MongoDB 自动重排？
MongoDB 聚合管道在执行前会进入优化阶段，$limit 是重点重排对象之一。优化器的目标很实际：尽早减少文档数量，降低后续阶段的计算压力。
- 如果 $limit 紧跟在 $sort 后面（且中间没有 $match、$project 等干预），优化器会把 $limit “吸收”进 $sort，让 $sort 只维护前
n个元素，而不是全量排序再截断 - 如果 $limit 前有 $match，优化器通常不会动它；但若 $match 后还有 $project 或 $addFields，而 $match 条件只依赖原始字段（比如
{status: "active"}），那么这个 $match 会被提前到所有投影阶段之前——此时 $limit 的相对位置虽没变，但实际生效的数据量已大幅下降 - 用
db.collection.aggregate([...], {explain: true})能看到优化后的管道，里面常出现原本没写的 $match 阶段，就是这个机制在起作用
$limit 放在 $sort 前面会发生什么？
语法上允许，但逻辑上危险：$limit 会先随机截断一批文档，$sort 再对这批残缺数据排序——结果既不完整，也不稳定。
- 例如
[{$limit: 10}, {$sort: {score: -1}}]：从集合任意取 10 条，再按score排，完全无法保证拿到全局 Top 10 - 这种写法常见于误以为“先限流再排序更省资源”的直觉，实则破坏语义，且无法利用
score索引加速排序（因为排序输入已非全集） - 唯一合理场景是调试：快速看几条原始数据，不关心顺序或代表性
如何验证 $limit 是否真的生效于预期阶段？
不能只看返回结果数，得确认它作用在哪个数据集上。最直接的方式是结合 explain 和执行计划观察。
- 运行
db.orders.aggregate([{$match: {status: "shipped"}}, {$sort: {created_at: -1}}, {$limit: 5}], {explain: true}) - 在返回的
stages数组里找"$sort"阶段，检查其"limit"字段是否为5—— 如果有，说明已被合并优化；如果没有，说明 $limit 是独立阶段，且排序仍需处理全部匹配文档 - 再对比去掉 $limit 后的
executionStats.nReturned，如果相差极大（比如从 10 万降到 5），说明 $limit 确实大幅减少了下游压力；如果几乎不变，可能是前面缺少有效 $match，或者索引未命中
排序 + limit 组合必须加 _id 的真实原因
不是为了“好看”或“规范”，而是防止并发写入下结果漂移。MongoDB 不保证对重复值字段（如 score: 95 出现多次）的排序稳定性。
- 两次执行
[{$sort: {score: -1}}, {$limit: 5}]，可能返回不同的 5 条文档，尤其当集合正被高频更新时 - 加
_id是最轻量的破歧义方式：{$sort: {score: -1, _id: -1}}让每条记录都有唯一排序键，结果确定可重现 - 不要用业务字段（如
username）替代_id，除非它本身是唯一且不可变的；否则仍存在歧义风险
真正难的不是写对 $limit，而是理解它何时被优化器“拿走”、何时被索引忽略、何时因排序缺失唯一键而悄悄出错——这些细节藏在 explain 输出和实际执行计划里，不在文档示例中。
