刚接手一个分析类需求，后端同事抛过来一条慢查询日志，让我帮忙看下。我扫了一眼那条聚合管道，几十行里塞了七八个阶段，其中 $group 用得极其别扭——把本该在分组阶段算完的东西全扔到下游用 $project 硬掰，跑了三秒多才出结果。
后来我给他改了一版，半小时后他跑过来说：查询从三秒降到两百毫秒，而且代码读起来顺多了。他说自己一直没搞明白 $group 到底该怎么用，总觉得它就是"分个组"，至于分组之后能干什么、什么时候用、怎么优化，全凭感觉。
这篇文章我就把 $group 这个阶段从原理到实战完整捋一遍。我会覆盖分组键怎么设计、累加器怎么选、和 $sort / $project / $unwind 怎么配合、内存限制和性能优化的那些坑、以及调试排错时我自己常用的套路。无论你是刚接触聚合管道，还是已经写过不少管道但总是模棱两可，这篇文章应该都能给你一些新东西。
1. 为什么 $group 是聚合管道里最容易被误解的阶段
1.1 表面是分组，本质是"折叠"
$group 的中文翻译是"分组"，这个翻译其实有点误导。很多人看到"分组"就以为它只是把数据按照某个字段归类，像 SQL 里的 GROUP BY 那样简单。但实际上，$group 在 MongoDB 里的角色更像是函数式编程里的"折叠"（fold / reduce）——它把一个集合里的所有文档，按照你指定的规则折叠成一组新的文档。
这个区别非常重要。SQL 的 GROUP BY 通常是配合聚合函数一起出现的，SELECT 子句里出现的非聚合列几乎必须是分组列，否则语义就错了。而 MongoDB 的 $group 不一样，它输出的每个文档，其字段完全由你决定——你可以只输出分组键，也可以输出若干个聚合结果，还可以用 $push / $addToSet 把一组原始文档"打包"进一个数组字段里。
换句话说，MongoDB 的 $group 不只是分组，它同时承担了"聚合计算"和"数据重塑"两件事。理解这一点之后，你再回头看那些写法别扭的管道，会发现很多问题都出在"该用 $group 完成的数据重塑动作，被挪到了后面的阶段里用一堆 $project、$unwind 硬凑"。
1.2 一个最朴素的例子，先跑通再说
先看一个最简单的例子。假设我在某电商场景里维护了一个订单集合 orders，里面每条文档大致长这样：
{ _id: ObjectId("..."), userId: "u1001", status: "completed", amount: 299, channel: "app", createdAt: ISODate("2025-01-14T10:23:00Z") }现在我要统计不同的订单状态各有多少单，按 status 分组，然后数一下每组有多少条文档：
db.orders.aggregate([ { $group: { _id: "$status", count: { $sum: 1 } } } ])这条管道跑完，输出大概长这样：
[ { _id: "completed", count: 847 }, { _id: "pending", count: 132 }, { _id: "canceled", count: 58 } ]这个例子里有三件事需要特别注意。
第一，$group 的第一个字段必须叫 _id，它定义分组键。这个 _id 的值可以是字段引用（像 "$status"），也可以是表达式、嵌套对象、甚至数组，后面我会专门讲。
第二，除了 _id 之外的其他字段，都必须配合累加器表达式（accumulator）来定义。在 MongoDB 里，你可以用 $sum、$avg、$min、$max、$first、$last、$push、$addToSet 等操作符来告诉数据库"这一组数据要如何折叠成输出字段"。你不能像 SQL 那样直接写status: "$status"然后指望它输出一个原始值——聚合管道的每个阶段只做自己定义好的事。
第三，$group 输出的字段顺序和原始集合顺序没有必然关系，它只保证分组结果本身是确定的（同一份输入数据，跑出来的结果是一致的）。如果你关心输出文档的排序，必须在 $group 之后显式加 $sort。
2. 分组键设计的四个实用层次
2.1 单字段分组与多字段分组
分组键最简单的情况就是按单一字段分组，前面那个例子已经演示过了。但实际业务里更常见的是多字段组合分组，比如"按用户和渠道统计订单金额"：
db.orders.aggregate([ { $group: { _id: { userId: "$userId", channel: "$channel" }, totalAmount: { $sum: "$amount" }, avgAmount: { $avg: "$amount" }, orderCount: { $sum: 1 } } } ])输出文档里的 _id 会变成一个嵌套对象：
[ { _id: { userId: "u1001", channel: "app" }, totalAmount: 1598, avgAmount: 399.5, orderCount: 4 } ]这里有个小技巧：如果你不想让分组的输出长成嵌套对象，可以在 $group 之后接一个 $project，把 _id 里的字段"展开"回顶层：
db.orders.aggregate([ { $group: { _id: { userId: "$userId", channel: "$channel" }, totalAmount: { $sum: "$amount" } } }, { $project: { _id: 0, userId: "$_id.userId", channel: "$_id.channel", totalAmount: 1 } } ])这种做法的好处是下游如果要继续做 join 或导出到报表，字段在顶层处理起来更方便。坏处是多一个阶段，管道会稍微慢一点。但如果分组键字段不多、数据量也不大，这个开销基本可以忽略。
2.2 用表达式做分组键
分组键不一定非得是某个字段本身，它可以是任意表达式。最常见的场景是按时间维度分组。
比如我想按"天"统计订单金额，但 createdAt 是精确到毫秒的时间戳，直接拿它分组没有意义。正确的做法是先通过 $dateToString 或 $dateTrunc 把时间"降维"到天，再作为分组键：
db.orders.aggregate([ { $group: { _id: { $dateToString: { format: "%Y-%m-%d", date: "$createdAt", timezone: "+08:00" } }, totalAmount: { $sum: "$amount" }, orderCount: { $sum: 1 } } }, { $sort: { _id: 1 } } ])这种写法特别适合做报表接口。我见过不少人先写一个 $project 把 createDate 字符串抽出来，然后再 $group，其实完全没有必要——表达式直接放在 _id 里，省掉一个阶段，管道既短又清晰。
再举一个例子。如果订单表里有个 amount 字段，我想按金额区间分组（比如 0-100、100-500、500 以上），可以用 $switch 或 $cond 构造区间标签：
db.orders.aggregate([ { $group: { _id: { $switch: { branches: [ { case: { $lt: ["$amount", 100] }, then: "0-99" }, { case: { $lt: ["$amount", 500] }, then: "100-499" } ], default: "500+" } }, orderCount: { $sum: 1 }, totalAmount: { $sum: "$amount" } } } ])这里有个需要注意的点：$switch 的 case 是按顺序判定的，所以先写小金额区间、再写大金额区间，逻辑上是安全的。如果你用 $cond 嵌套，同样要把最严格的判断放在最外层，否则区间会互相覆盖。
2.3 数组与嵌套字段作为分组键
分组键可以是数组。这个特性很多人不知道，但它在某些场景下非常好用。
比如商品集合 products 里，每个商品有一个 tags 数组：
{ _id: ObjectId("..."), name: "无线鼠标", tags: ["办公", "外设", "无线"], price: 129 }如果我想统计"每个标签下的商品数量和平均价格"，直觉上应该先 $unwind 把 tags 展开，再 $group。但 MongoDB 允许你直接把数组作为 _id，写法是这样的：
db.products.aggregate([ { $group: { _id: "$tags", count: { $sum: 1 } } } ])这样输出的每个分组，_id 就是某个商品完整的标签数组。它和"按标签统计"不是一回事——它是按"标签组合"统计。比如 {"办公", "外设", "无线"} 会成为一个组，{"办公", "外设"} 是另一个组。这种分组适合做"组合标签的受众分析"，比如看哪些标签组合的客单价更高。
嵌套字段的分组也很直接。假如订单里嵌套了 address 对象，里面有 city 字段，你想按城市统计，写 "$address.city" 就行了：
db.orders.aggregate([ { $group: { _id: "$address.city", totalAmount: { $sum: "$amount" } } } ])点号路径访问嵌套字段是 MongoDB 的常规操作，在 $group 的 _id 里同样适用。唯一的坑在于，如果某个文档里 address 是 null 或缺失，这个文档会被分到 _id 为 null 的组里。后面我会专门讲这个坑怎么处理。
2.4 空值分组的坑与处理
这是一个非常容易踩的坑。当你按某个字段分组时，如果集合里有一部分文档的这个字段是 null 或不存在，它们会被统一归到 _id: null 这一组。
很多报表接口里，这个 null 组会莫名其妙地出现，让人摸不着头脑。比如按渠道分组统计金额，突然冒出一行 _id: null、totalAmount 很大的记录，你根本不知道这些订单来自哪里。
我有两个处理习惯。
第一个习惯是在 $group 之前先过滤。如果 null 组的文档不是业务需要的（比如缺少关键渠道信息的脏数据），就用 $match 把它们排除掉：
db.orders.aggregate([ { $match: { channel: { $ne: null } } }, { $group: { _id: "$channel", totalAmount: { $sum: "$amount" } } } ])第二个习惯是主动标记。如果这些 null 值文档是有业务意义的（比如"渠道未知"的订单也要统计），那我建议把它们映射成一个显式的标签，而不是让它们默认变成 null：
db.orders.aggregate([ { $group: { _id: { $ifNull: ["$channel", "unknown"] }, totalAmount: { $sum: "$amount" } } } ])这样输出的结果里会有一条 _id: "unknown" 的记录，下游的报表开发看到这个值就能立即明白它的含义，不会产生误解。
3. 累加器选型与组合的实战经验
3.1 五个常用累加器各自的使用场景
$group 里的累加器是整套聚合管道的灵魂，选对累加器，你的管道会又短又清晰；选错了，你就得在管道里加各种奇怪的阶段去凑。我把常用累加器按使用频率排个序，逐个说。
$sum是最基础也最常用的，它对数值求和，也可以配合 $sum: 1 来计数。注意 $sum 也支持表达式，比如 $sum: { $multiply: ["$price", "$quantity"] } 可以直接求"订单总金额的合计"，不需要事先把金额算好。
$avg用于求平均，它的写法和其他数据库的习惯略有不同——不是 $avg("$field")，而是 $avg: "$field"。它同样支持表达式。我用 $avg 的时候会特别留意精度问题，MongoDB 返回的是 double，如果业务要求保留两位小数，一般会在 $project 阶段用 $round 处理。
$min / $max用于求极值，在"取每组最早/最晚时间""取每组最大金额"这类场景非常实用。我经常把它们和 $first / $last 混淆，这里要特别说明：$min / $max 是对整个组做极值计算，而 $first / $last 是取"按当前输入顺序排列后的第一个或最后一个文档的字段值"。如果组内数据没有明确排序，$first / $last 的结果是不可预期的。
$push是"把该组所有文档的某个字段收集成数组"。它在做"每个用户的所有订单ID""每个分类下的所有商品名"这类场景非常好用。但要注意内存问题：如果一个组有十万条文档，$push 会把十万个元素都放进一个数组字段里，这非常占内存。我在生产环境对 $push 的结果都会做一层限制，要么在 $group 之前 $limit，要么在之后用 $slice 截断。
$addToSet和 $push 类似，但它会自动去重。它的性能比 $push 差，因为要维护一个集合来判断重复，但在"每个用户购买过哪些不同的渠道"这种场景里是唯一合适的选择。
我把这几个累加器的对比整理成了表格：
| 累加器 | 作用 | 典型场景 | 注意事项 |
|---|---|---|---|
| $sum | 求和 / 计数 | 金额汇总、订单数量 | $sum: 1 是最常用的计数写法 |
| $avg | 求平均 | 客单价、平均分 | 返回 double，注意精度 |
| $min / $max | 求极值 | 最早/最晚时间、最高/低价 | 与 $first / $last 有本质区别 |
| $push | 收集成数组 | 组内明细列表 | 大组慎用，内存压力大 |
| $addToSet | 收集并去重 | 用户去重渠道列表 | 性能比 $push 差 |
3.2 一个案例里同时用四个累加器
理论说多了容易飘，还是直接看一个综合案例。假设有一个运营报表需求：按用户统计订单概览，需要输出每个用户的订单总数、总金额、平均金额、首次下单时间和最近下单时间。
db.orders.aggregate([ { $group: { _id: "$userId", orderCount: { $sum: 1 }, totalAmount: { $sum: "$amount" }, avgAmount: { $avg: "$amount" }, firstOrderAt: { $min: "$createdAt" }, lastOrderAt: { $max: "$createdAt" } } }, { $sort: { totalAmount: -1 } }, { $limit: 100 } ])这条管道能在单次数据库扫描里完成全部统计，不需要在应用层逐条累加，计算效率远高于把数据拉回内存自己算。注意排序阶段放在 $group 之后，因为 totalAmount 是分组阶段的输出字段，原始集合里并没有这个字段，你没法在 $group 之前对它排序。
3.3 累加器字段的命名与下游使用的坑
给累加器输出字段起名看起来是小事，但字段名起得不好，后面的 $project、$sort、$match 都会跟着遭殃。
我个人的习惯是输出字段名直接体现语义，比如 totalAmount、orderCount、firstOrderAt。尽量不要用 a、b、c 这种缩写，因为在管道越来越长之后，你根本记不清 b 到底是平均金额还是最大金额，调试起来非常痛苦。
另外有个特别容易踩的坑：当你用 $group 输出了一个字段（比如 count），在后面 $sort 的时候写{ count: -1 }，这是没问题的。但如果你在 $match 里想过滤 count，就会发现 $match 不能直接引用 $group 刚算出来的别名——$match 在管道里只能处理"当前阶段的输入文档"，也就是说你得再加一个 $project 或者直接用 $group 之后的聚合管道语义。最常见的方式是先把 $match 放在 $group 之前做一些粗过滤，或者在 $group 之后用 $sort + $limit 代替对聚合结果的过滤。
这里我多说一句：你可以在 $group 里用 $$ROOT 配合 $push 实现比较复杂的"分组内保留整个原始文档"需求。比如我想把每个用户最近的订单都保留下来：
db.orders.aggregate([ { $sort: { createdAt: -1 } }, { $group: { _id: "$userId", latestOrders: { $push: "$$ROOT" } } }, { $project: { _id: 1, latestOrders: { $slice: ["$latestOrders", 5] } } } ])这里先用 $sort 把订单按时间倒序，然后 $group 里用 $push 把整个文档推进数组，最后用 $slice 截断前 5 条。如果不先排序，$push 的顺序就是 MongoDB 从磁盘读取的自然顺序，这个顺序通常没有任何业务意义，结果就不可靠。
4. 与 $sort、$project、$match 等阶段的前后搭配
4.1 为什么 $sort 要放在 $group 后面而不是前面
很多新手喜欢把 $sort 放在管道开头，觉得"先排好序再分组肯定没错"。但在大多数场景下，这种直觉是错误的，而且代价很大。
$group 本身的输出顺序是未定义的。即使你在前面排好序，$group 在内存里做哈希分组时，输出顺序依然可能被打乱。所以如果你关心最终结果的排序，$sort 必须放在 $group 之后，对分组结果排序。
更关键的是，在 $group 之前做全量排序通常没有必要。如果你要的是"每个组内部按时间倒序取第一条"，那你需要在 $group 之前排序，然后配合 $first 或 $push 来用；如果你要的是"分组之后按总金额倒序排"，那排序只能放在 $group 之后。
两种需求对应两种完全不同的管道结构：
// 需求A：每个用户取最近一笔订单 db.orders.aggregate([ { $sort: { createdAt: -1 } }, { $group: { _id: "$userId", latestOrder: { $first: "$$ROOT" } } } ]) // 需求B：按用户总金额倒序输出TOP 100 db.orders.aggregate([ { $group: { _id: "$userId", totalAmount: { $sum: "$amount" } } }, { $sort: { totalAmount: -1 } }, { $limit: 100 } ])需求A里，$sort 在 $group 之前是有意义的，因为 $first 取的是"输入流中的第一个文档"，不排序就无法保证取到的是时间最新的那一条。需求B里，$sort 只能在 $group 之后。
4.2 $match 前移与后置的区别
$match 是聚合管道里最廉价的过滤操作——它能在数据进入 $group 之前就大幅减少参与分组的文档数，从而显著降低内存和 CPU 开销。所以有一条经验法则：能前移的 $match 一定要前移。
比如"只统计已完成订单的金额"：
// 推荐写法：先过滤再分组 db.orders.aggregate([ { $match: { status: "completed" } }, { $group: { _id: "$userId", totalAmount: { $sum: "$amount" } } } ])如果你把这个 $match 写在 $group 后面，虽然结果一样，但数据库已经对所有订单都做了分组计算，再过滤组结果，浪费显然更大。尤其当集合里只有 10% 的订单是已完成时，先过滤能把参与分组的文档数砍掉 90%，性能差距非常明显。
4.3 $project 在 $group 前后承担的不同任务
$project 在 $group 之前的任务是"瘦身"和"预处理"：只保留分组需要的字段，或者用表达式计算新的中间字段。比如我只需要用到 amount 和 status，但原始文档很大，这时可以在 $group 前先 $project 瘦身：
db.orders.aggregate([ { $project: { status: 1, amount: 1, month: { $dateToString: { format: "%Y-%m", date: "$createdAt" } } } }, { $match: { status: "completed" } }, { $group: { _id: "$month", totalAmount: { $sum: "$amount" } } } ])这里把 $dateToString 放在 $project 里，是为了让 $group 的分组键直接用 month 这个中间字段。这个写法比在 $group 的 _id 里直接写表达式更易读，虽然多一个阶段，但代码清晰度更高。
$project 在 $group 之后的任务通常是"重塑输出结构"：去掉嵌套的 _id、改字段名、重新计算展示层字段。这在前面已经讲过了，不加赘述。
4.4 $unwind 与 $group 的配合：先打散再聚合
$unwind 的作用是把数组字段"打散"成多条文档。它和 $group 配合，能解决一类特别常见的需求："统计数组元素维度的数据"。
举一个购物的例子。每个订单里有一个 items 数组：
{ _id: ObjectId("..."), userId: "u1001", items: [ { sku: "sku_a", qty: 2, price: 49.9 }, { sku: "sku_b", qty: 1, price: 199 } ] }如果想统计每个 SKU 卖了多少件、总销售额是多少，直接 $group 是不行的，因为 items 是数组。你得先 $unwind 按条展开，再 $group：
db.orders.aggregate([ { $unwind: "$items" }, { $group: { _id: "$items.sku", totalQty: { $sum: "$items.qty" }, totalSales: { $sum: { $multiply: ["$items.qty", "$items.price"] } } } }, { $sort: { totalSales: -1 } } ])$unwind 在管道里是比较昂贵的操作，因为它会把一条文档复制成多条。如果订单里平均有 5 个商品，$unwind 之后的数据量就是原来的 5 倍。所以使用 $unwind 之前一定要想清楚：是不是真的需要打散？如果不关心数组里每个元素的独立统计，而只是要"整个数组的长度"，用 $size 更划算。
另外 $unwind 有一个容易被忽视的坑：默认情况下，如果某条文档的 items 字段是 null、缺失或者空数组，这条文档会在 $unwind 阶段被直接丢弃。如果想保留这些文档，需要加 preserveNullAndEmptyArrays 选项：
db.orders.aggregate([ { $unwind: { path: "$items", preserveNullAndEmptyArrays: true } }, { $group: { _id: "$userId", itemCount: { $sum: { $cond: [{ $isArray: "$items" }, 1, 0] } } } } ])当然，这个例子只是为了演示保留选项的写法。实际业务里如果用户没有购买任何商品，也要统计这个用户的订单数，那必须用 preserveNullAndEmptyArrays，否则这类用户就永远消失了。
5. 内存限制、allowDiskUse 与 $group 性能优化
5.1 100MB 内存限制的由来与表现
$group 在实现上是一个哈希聚合：数据库会把所有分组键放到内存里，一边读文档一边累加。为了避免单个操作耗尽服务器内存，MongoDB 对聚合管道有一个硬性限制——单个阶段最多使用 100MB 内存。超过这个限制，就会报错，错误信息大致是：
PlanExecutor error during aggregation: ... Exceeded memory limit这个错误在生产环境非常常见。触发它的大多是 $group、$sort、$unwind 这种需要占用大量中间内存的阶段。尤其是 $group 配合 $push 把数万条文档塞进数组，100MB 一下就没了。
解决这个限制最直接的方式是开启 allowDiskUse。它允许聚合操作在内存不足时把中间结果写入磁盘临时文件：
db.orders.aggregate( [ { $group: { _id: "$userId", orders: { $push: "$$ROOT" } } } ], { allowDiskUse: true } )allowDiskUse 能解决问题，但它是"用磁盘换内存"，性能会有折扣。我在生产环境的原则是：能不开就不开，因为它意味着这个聚合操作已经进入了"较重"的路径；但如果是定期的后台分析任务（比如凌晨跑的报表任务），开一下完全没问题。
5.2 减少 $group 内存压力的四个手段
与其等内存超限再开 allowDiskUse，不如从源头减少 $group 的内存压力。我总结了自己常用的四个手段。
第一个是尽量前移 $match。这不仅减少参与分组的文档数，也减少了分组键的数量。试想按 userId 分组，如果全表有 5000 万条订单、1000 万用户，而最近 30 天的订单只有 100 万条覆盖 10 万用户，先 $match 后 $group，内存占用直接少两个数量级。
第二个是少用 $push 全量收集。很多需求只是"展示每个组内的前几条记录"，完全不需要把整个组的所有文档都收集到数组里。这时可以先在组内做一次 $sort，然后用 $push 加 $slice 截断，或者干脆用 $first / $last 只取需要的字段。
第三个是用 $project 提前裁剪字段。如果原始文档很宽（比如有 30 个字段），$group 即使只是 $push: "$$ROOT"，也会把 30 个字段全复制进数组。先 $project 只留下需要的字段，内存能省一大半。
第四个是控制数据量上限。如果这个分析任务只是给运营看一个大概趋势，那就没必要对全量历史数据做聚合，用时间字段加 $match 限制范围即可。我在很多项目里发现，所谓"全量报表"，其实用户只看最近 90 天的趋势。
5.3 用索引覆盖 $match 条件
$group 本身没法用索引，但它之前的 $match 可以。如果你的管道结构是 $match → $group，那么给 $match 的过滤字段建索引，能让数据库只读取符合条件的文档，而不是全表扫描，收益非常直观。
举例，还是前面那个按用户统计已完成订单的管道：
db.orders.aggregate([ { $match: { status: "completed" } }, { $group: { _id: "$userId", totalAmount: { $sum: "$amount" } } } ])给 status 建一个普通单字段索引就能看到明显加速：
db.orders.createIndex({ status: 1 })如果 $match 条件里还有时间范围，建议建复合索引，比如{ status: 1, createdAt: -1 }。这里要注意索引字段的顺序：等值筛选字段（status）放前面，范围筛选字段（createdAt）放后面，数据库才能高效地利用索引完成过滤。
5.4 $group 之前的大数据排序：一个优化案例
分享一个真实场景。某数据分析模块需要产出"每个用户最近一次活跃时间"，用户表有 300 万条文档，活跃日志表有 8000 万条。最初的管道是这样写的：
// 低效版本 db.activityLogs.aggregate([ { $group: { _id: "$userId", lastActiveAt: { $max: "$activeAt" } } } ])这个版本其实已经不错了，用 $max 直接在分组阶段算极值，不涉及全量排序，跑起来大概 30 秒。问题在于同事第一次写的时候不是这个版本，他先 $sort 再 $group 再 $first：
// 低效版本：先全量排序 db.activityLogs.aggregate([ { $sort: { activeAt: -1 } }, { $group: { _id: "$userId", lastActiveAt: { $first: "$activeAt" } } } ])这个版本要对 8000 万条日志全量排序，再分组，两次内存密集操作叠加，直接触发了 100MB 内存限制，开了 allowDiskUse 后还要跑 3 分钟以上。改成 $max 之后，$group 内部只需要维护每个用户的当前最大值，内存占用极小，速度提升明显。
这个案例说明了一个通用原则：只要目标是"每组某个字段的极值/汇总值"，就优先用 $min / $max / $sum / $avg 直接在 $group 里算，不要绕道 $sort + $first / $last。$sort + $first 只适用于"组内按某个字段排序后取整个文档"这种 $min / $max 无法替代的场景。
6. 用 $group 重命名输出结构的常用套路
6.1 把嵌套 _id 展开成扁平字段
我在前面已经提过 $project 展开嵌套 _id 的写法，这里再补充一个更完整的例子，因为实际业务里经常遇到"接口规范要求扁平 JSON，但聚合输出是嵌套结构"的冲突。
db.orders.aggregate([ { $group: { _id: { userId: "$userId", channel: "$channel" }, totalAmount: { $sum: "$amount" } } }, { $project: { _id: 0, userId: "$_id.userId", channel: "$_id.channel", totalAmount: 1, // 顺手把金额格式化到两位小数 formattedAmount: { $round: ["$totalAmount", 2] } } } ])注意 $project 里 _id: 0 是把默认的 _id 字段去掉，免得输出里出现多余字段。如果你把 _id 设为 0，但又引用 $_id 的字段，这个引用依然有效，因为 $project 引用的输入文档里的 $_id 还在，只是输出时不带它。这个逻辑很多人第一次接触会搞混，理解成"输出时去掉 _id 但可以用它的子字段"就顺了。
6.2 在 $group 内直接构造输出结构
除了 $project 事后重塑，你还可以在 $group 阶段直接构造输出结构。方式就是给累加器字段起一个有意义的名字，把分组键也放在 _id 里。唯一的限制是 $group 的输出字段必须是累加器表达式的结果，不能是普通字段的透传。
如果你确实需要"分组后每组保留某个原始字段值"，而且这个值在同一组内是固定的（比如按渠道分组，渠道名称本身就是分组键），那直接用 _id 即可，不需要额外透传。如果你需要的是"每组内某个字段值，但取哪条不确定"，你得用 $first 或 $last。
6.3 输出字段里嵌套文档的构造
$group 的输出结构不只是扁平字段，你完全可以构造嵌套文档。做法是在累加器里用 $push 配合文档字面量：
db.orders.aggregate([ { $group: { _id: "$userId", orders: { $push: { orderId: "$_id", amount: "$amount", createdAt: "$createdAt" } } } }, { $project: { _id: 0, userId: "$_id", totalOrders: { $size: "$orders" }, orders: { $slice: ["$orders", 10] } } } ])这个写法在做"用户最近订单列表"接口时非常舒服。先 $sort: { createdAt: -1 }，再 $group 用 $push 收集，最后 $project 用 $slice 截断。整个管道一共三个阶段，逻辑清晰且性能可控。
7. 调试聚合管道时我常用的三个手段
7.1 阶段逐个验证，而不是一把梭
聚合管道越长，出了问题越难定位。我的习惯是每次只调试到当前阶段，确认输出符合预期，再往后接下一个阶段。
比如我先跑：
db.orders.aggregate([ { $group: { _id: "$userId", totalAmount: { $sum: "$amount" } } }, { $limit: 5 } ])看输出是否合理，再接着验证 $sort 和 $limit，这样每一步的预期都很明确。一旦结果不对，你立刻能知道是分组键写错了还是累加器选错了，而不是在十来个阶段里盲目寻找。
7.2 用 $match 缩小数据范围定位问题
调试时不要直接对全量数据跑，先加一个 $match 把数据范围缩小到你能手工核对的程度。比如：
db.orders.aggregate([ { $match: { userId: "u1001" } }, { $group: { _id: "$channel", totalAmount: { $sum: "$amount" } } } ])然后你可以跑一条简单的查询：
db.orders.find({ userId: "u1001" }).sort({ channel: 1 })手工把金额加起来，和聚合结果核对。如果对上，说明管道逻辑没问题；对不上，就缩小范围继续排查。
7.3 用 $out 或者临时集合保存中间结果
有些复杂的管道，调试某个中间阶段时需要反复查看每个阶段的输出。我常用的一个土办法是：把上一个阶段的输出写到一个临时集合，然后直接查询这个集合来检查，而不是在终端里一遍遍滚动输出。
db.orders.aggregate([ { $match: { status: "completed" } }, { $group: { _id: "$userId", totalAmount: { $sum: "$amount" } } }, { $out: "temp_user_stats" } ]) db.temp_user_stats.find({ totalAmount: { $gt: 1000 } }).limit(10)注意 $out 必须是管道的最后一个阶段，它的作用是覆盖写入一个集合。调试完后记得清理临时集合，不要留在库里污染数据。
8. 一个完整的综合案例：运营看板月度订单分析
理论讲了这么多，最后用一个贴近实战的综合案例把所有内容串起来。
需求是这样的：某业务方需要一份月度订单分析看板，展示每个月的订单总数、总销售额、成功订单数和失败订单数，并且能按月份倒序查看最近 6 个月的趋势。订单集合 orders 里包含以下字段：
- createdAt：下单时间
- status：订单状态，取值有 completed / failed / pending
- amount：订单金额
- channel：下单渠道，可能有缺失
分析一下这个需求，有几个核心决策点：
第一，按月份分组。createdAt 是精确到毫秒的日期，得先用 $dateToString 转成月份字符串。
第二，需要同时求多个聚合结果。订单总数用 $sum: 1，总销售额用 $sum: "$amount"，成功/失败订单数得用条件表达式配合 $sum。
第三，月份要倒序，并且只保留最近 6 个月。因为月份是 $group 生成的，$sort 和 $limit 都得放后面。
管道可以这样写：
db.orders.aggregate([ { // 过滤下单时间，只看最近 6 个月的数据 $match: { createdAt: { $gte: new Date("2025-01-01T00:00:00Z"), $lt: new Date("2025-07-01T00:00:00Z") } } }, { $group: { _id: { $dateToString: { format: "%Y-%m", date: "$createdAt", timezone: "+08:00" } }, totalOrderCount: { $sum: 1 }, totalAmount: { $sum: "$amount" }, completedCount: { $sum: { $cond: [{ $eq: ["$status", "completed"] }, 1, 0] } }, failedCount: { $sum: { $cond: [{ $eq: ["$status", "failed"] }, 1, 0] } } } }, { // 重命名月份字段，顺便调整输出结构 $project: { _id: 0, month: "$_id", totalOrderCount: 1, totalAmount: 1, completedCount: 1, failedCount: 1, successRate: { $round: [ { $divide: [ "$completedCount", { $add: ["$completedCount", "$failedCount"] } ] }, 2 ] } } }, { $sort: { month: -1 } }, { $limit: 6 } ])这个管道的优点在于：$match 先把时间范围缩到半年，$group 一次性算出所有统计指标，$project 做最后的字段整理和成功率计算，排序和限制放最后。每个阶段职责单一，没有多余的重复计算。数据量在百万级以内时，响应速度非常快。
写完后我总是会再检查一遍：分组键的时区是否和业务口径一致？成功率是否可能因为除零而报错？如果某个月份没有 failed 订单，$add: ["$completedCount", "$failedCount"] 的值不会是 0，因为至少 completedCount 是大于等于 0 的——不对，如果某个月份既没有 completed 也没有 failed，只有 pending 订单，那分母就是 0，$divide 会返回 null。这个问题在只有 pending 状态的月份会出现。稳妥的做法是加一个 $cond 判断分母是否为 0：
successRate: { $cond: [ { $eq: [{ $add: ["$completedCount", "$failedCount"] }, 0] }, 0, { $round: [ { $divide: ["$completedCount", { $add: ["$completedCount", "$failedCount"] }] }, 2 ] } ] }这种边界条件，恰恰是实际开发中最容易漏掉的。所以我一直有个习惯：写聚合管道时，先考虑"数据不满足假设"的情况，再考虑"数据满足假设"的情况。
9. 我自己踩过的一个 $group 相关的坑，以及现在怎么规避
最后分享一个我实际遇到过的坑，它让我对 $group 的认知上了一个台阶。
有段时间我做一个用户标签统计任务，需要对用户行为日志按 userId 分组，然后把每个用户最近 30 天访问过的页面ID收集到数组里。我最初写的管道是：
db.behaviorLogs.aggregate([ { $match: { createdAt: { $gte: thirtyDaysAgo } } }, { $sort: { userId: 1, visitedAt: -1 } }, { $group: { _id: "$userId", pages: { $push: "$pageId" } } }, { $project: { _id: 0, userId: "$_id", pages: { $slice: ["$pages", 20] } } } ])表面看逻辑没问题：先过滤，再排序，然后分组把页面ID收集到数组，最后截断 20 个。但跑在 2000 万条日志上，这个管道慢得离谱，还频繁触发内存超限错误。
排查之后发现，真正的瓶颈不在 $group 本身，而在 $sort。$sort 要对 2000 万条文档按 userId 和 visitedAt 做全量排序，排序结果要交给 $group，而 $group 的 $push 又把全量页面ID都收集了一遍——排序和 push 两件内存大户叠加，硬生生把内存打爆了。
后来我换了一个思路：既然只需要每个用户最近的 20 个页面ID，完全不需要把全量页面ID都收集到数组里再截断。MongoDB 从 4.4 版本开始支持 $group 内部对 $push 的操作顺序做配合，但受限于算子实现，最通用的优化还是"先按用户分桶，组内排序取前N，再收集"。
我最终确认的写法是利用 $push 的字段顺序特性，先全局按 visitedAt 倒序排序，这样收集时天然从新到旧，然后在 $project 阶段用 $slice 截断前 20 个。关键在于全局排序的代价依然很大。
真正让我彻底想明白的，是这个任务的本质：它其实不需要全局排序，它需要的是"每个用户内部按时间倒序取前 20 个页面ID"。这个需求可以用一个更轻量的两段聚合思路实现：先按 userId 和 visitedAt 建一个排序游标，然后用 $group 的 $push + $first 配合子查询来分段处理。但实际操作中，我发现一个更简单粗暴却非常有效的优化——先按 userId 分组聚合，把 visitedAt 和 pageId 打包成对象数组，然后只对数组按 visitedAt 排序，最终再截断：
db.behaviorLogs.aggregate([ { $match: { createdAt: { $gte: thirtyDaysAgo } } }, { $group: { _id: "$userId", visitRecords: { $push: { pageId: "$pageId", visitedAt: "$visitedAt" } } } }, { $project: { _id: 0, userId: "$_id", latestPages: { $map: { input: { $slice: [ { $sortArray: { input: "$visitRecords", sortBy: { visitedAt: -1 } } }, 0, 20 ] }, as: "rec", in: "$$rec.pageId" } } } } ])这个方案虽然多了一个 $sortArray 操作，但它的作用范围是"每个用户组内的数组"，而不是全局 2000 万条文档。分组之后，每个用户的 visitRecords 长度通常在几十到几百之间，在这个规模上做组内排序开销极小。和之前的全局排序相比，性能差距能到一个数量级。
这个教训让我总结出一个方法论：遇到"每组取 Top N"的需求时，先问自己——能不能先分组、让排序发生在组内？如果能，就一定不要全局排序再加 $first / $push 截断。全局排序是聚合管道里最昂贵的操作之一，把它变成组内排序，是这类需求最核心的优化手段。
10. $group 的进阶边界：什么时候不该用 $group
写了这么多怎么用 $group，最后也想聊聊什么时候不该用它。这是我观察到的另一类常见问题——很多人把 $group 当作万能药，结果把管道写得又重又慢。
第一种情况是数据量极大的去重统计。比如统计某字段有多少个不同值，如果你天真地用 $group + $addToSet，内存压力会非常大。如果集合很大，这类需求更好的方式是使用 distinct 命令，或者用 $group 之前先 $project 只保留下那个字段，缩减传输数据量。本质上，$group 不是不能做，而是成本高，要评估清楚。
第二种情况是只需要简单分组计数，不需要下游加工。如果只是想知道"集合里每个状态各有多少条"，用单独的 count 命令配合查询条件，或者用 $group 但不输出过多字段，可以根据场景选择。我自己遇到过一次：一个接口只是想返回"completed / pending / failed 各多少条"，结果同事写了个 $group 加 $push 把明细也收集了，下游根本没用。多收集的字段让响应体大了好几倍，查询也慢了不少。
第三种情况是实时性要求很高的接口里，聚合计算过于复杂。$group 本身不慢，但管道一旦长了，每个阶段都有开销。如果线上接口的 QPS 很高，我更倾向于把聚合结果做成物化视图或缓存表，定时用聚合任务刷新，而不是每次请求都实时跑管道。
这个思路和 $group 本身的技巧无关，但对于架构设计来说是更重要的判断。工具用得再好，也要知道什么时候不用它。
最后说一句个人的体会。$group 这个操作符，表面上是 MongoDB 聚合管道里一个简单的分组步骤，但实际用起来，它牵扯到内存模型、排序策略、字段设计、管道阶段编排等多个方面。每一个细节处理得好，管道就能快得让人惊喜；处理不好，就是一条三秒起步的慢查询。我在这篇文章里提到的所有经验，都是从真实的线上问题里一点点磨出来的。如果你现在正好在调一条 $group 相关的管道，希望这篇内容能帮你少走几步弯路。
