结论：100mb内存限制错误主因是聚合管道书写不当——$match未前置、$project未精简字段、$group/$sort过早触发致中间结果膨胀；二者需全量加载文档，若前置过滤缺失，5000条20kb文档即超限。
直接说结论：100MB内存限制（Memory limit exceeded 错误）绝大多数情况不是因为数据量太大，而是聚合管道没写对——阶段顺序错、字段没裁剪、$group 或 $sort 过早触发导致中间结果膨胀。
为什么 $group 和 $sort 会触发内存超限
这两个阶段必须把所有匹配文档加载进内存才能完成分组或排序。如果 $match 放在它们后面，MongoDB 就得先拉出全部原始文档（可能含几十个字段、几MB大小），再分组——光一个文档 20KB，5000 条就占 100MB。
-
$group前未过滤：比如按user_id统计订单数，但没在开头用$match限定时间范围，结果扫描了三年全量订单 -
$sort前未投影：排序字段本身很小（如created_at），但文档带了description（长文本）、images（数组嵌套对象）等大字段，全被拖进内存 - 复合条件写在
$group后的$match：例如想筛出“总消费 > 10000 的用户”，却写成{$group: {...}}, {$match: {total: {$gt: 10000}}}，此时分组已做完，内存早已撑满
必须把 $match 提前，并叠加时间/状态等高选择性条件
MongoDB 只有最前面的 $match 阶段能走索引，后续的 $match 是内存过滤，不减数据量。
- 优先用高区分度字段：如
status: "completed"、created_at: {$gte: ...}，避免只用type: "order"这类低区分度条件 - 复合索引要匹配
$match字段顺序：若管道开头是{$match: {shop_id: ..., created_at: {...}}}，索引就得建为db.orders.createIndex({shop_id: 1, created_at: 1}) - 别依赖“自动重排”：虽然优化器会尝试移动部分
$match，但它不会跨过$lookup或$unwind，这些阶段前的$match必须手动写好
$project 不是可选动作，而是内存控制开关
$project 放在 $group 或 $sort 前，能直接砍掉 60%~90% 的中间数据体积——尤其当原始文档含二进制、长字符串或深层嵌套时。
- 只保留
$group用到的字段：比如按category分组求和，$project里只需{category: 1, amount: 1, _id: 0} - 显式排除
_id：除非分组键需要它，否则加_id: 0，避免默认携带这个 ObjectId（12 字节虽小，百万条也占 12MB） - 别在
$project里算新字段再用于后续$match：像{avgScore: {$avg: "$scores"}}+{$match: {avgScore: {$gt: 80}}}，这会让 MongoDB 无法前置过滤，avgScore 必须等$project执行完才存在
allowDiskUse 不是解药，而是兜底开关
设 allowDiskUse: true 确实能让 $group/$sort 落盘，但 I/O 开销会让查询从秒级变分钟级，且 Atlas 免费层默认禁用。
- 仅用于临时调试：加了它跑通后，立刻回头检查
$match位置和$project字段是否冗余 - 不能替代索引：即使落盘，
$match若没走索引，仍要扫全表再写临时文件 - Go 驱动中需显式传参：
collection.Aggregate(ctx, pipeline, options.Aggregate().SetAllowDiskUse(true))
真正卡住性能的，往往不是数据量，而是管道里多留了一个没用的字段、少写了一个时间范围、或者把 $match 拖到了 $lookup 后面——这些细节不改，加再多内存也没用。
