根本原因是$sort和$group必须全量加载输入文档至内存，若前置无$match过滤、无$project精简字段，即使数据量不大也会迅速突破100MB限制；索引仅对管道开头$match生效，allowDiskUse仅为兜底而非优化手段。
根本原因不是数据量大，而是排序或分组阶段被迫在内存里处理远超必要的文档——$sort 和 $group 这类阶段必须把所有输入文档一次性加载进内存才能开始工作，一旦前面没过滤、没精简，100MB 很快就满了。
为什么 $sort 和 $group 会直接爆内存
这两个阶段属于“阻塞型管道阶段”，它们不输出任何结果，直到全部输入文档都进来并完成计算。这意味着：
- 如果
$sort前面没有$match，它就得把整个集合（比如 50 万条订单）全拉进内存再排序 - 如果
$sort前没$project，每条文档里几 MB 的logs字段也会被一并拖进来，哪怕你只按updated_at排序 -
$group同理：没前置过滤的{$group: { _id: "$user_id", total: {$sum: "$amount"} }}，会为每个用户建一个分组桶，中间状态体积可能比原始文档还大
聚合管道顺序写错是最常见的根因
MongoDB 不会自动重排阶段，$match 必须手动放在最前面，且只有开头的 $match 能走索引；后面的 $match 只是内存过滤，对扫描量零影响。
- 错误写法：
[{$sort: {created_at: -1}}, {$match: {status: "completed"}}]→ 先全表排序，再过滤，内存早炸了 - 正确写法：
[{$match: {status: "completed", created_at: {$gte: ISODate("2026-01-01")}}}, {$sort: {created_at: -1}}] - 复合条件必须配复合索引：
db.orders.createIndex({status: 1, created_at: 1})，字段顺序不能反 -
$lookup或$unwind会中断$match下推，它们前面的$match必须手工补上
allowDiskUse 是兜底，不是优化解法
加 {allowDiskUse: true} 能让查询跑通，但只是把内存压力转成磁盘 I/O 压力，线上接口延迟可能从 50ms 涨到 2s+，而且 Atlas M0 免费版直接禁用它。
- 它只对
$sort、$group、$bucket等特定阶段生效，且必须写在aggregate()调用末尾，不能塞进 stage 里 - 即使开了，单文档仍受 16MB BSON 限制；结果太大时，得改用
$out写入临时集合 - MongoDB 6.0+ 默认开启
allowDiskUseByDefault: true，但老版本（如 5.0.13）必须显式传参，否则直接报错
真正难处理的是那些没法加索引的场景
比如字段结构松散、嵌套过深、或排序字段是动态生成的（如 "score_2026_q3" 这种带年份季度的键名），索引建不了，$project 也精简不了——这时候要么重构模型，要么接受分页查 + 应用层排序，别硬扛。
