MongoDB聚合框架中的 $count 阶段用于统计当前管道里剩余文档的数量，它不像 $group 那样需要指定分组依据，而是直接对整个文档流做一次计数操作。把 $count 放在管道末尾，聚合结果会变成一个只包含计数字段的单一文档，适合接口返回总数、分页查询或条件过滤后的数据量统计。很多人习惯用 $group 加 $sum 来计数，但 $count 可以省去多余的分组和投影步骤，代码更简洁。
一、$count 的基本语法与执行机制
$count 的语法非常直接，它接收一个字符串参数，用来指定输出字段的名称。例如要统计 orders 集合中的全部文档数量，可以这样写：
db.orders.aggregate([
{ $count: "total" }
])
执行后会返回类似 { "total" : 100000 } 这样的结果。这个阶段必须出现在聚合管道数组中，不能单独用于 find 查询。它可以处理从前面阶段流出的文档，例如经过 $match、$project、$group 等操作之后的结果。聚合引擎会遍历到达 $count 的所有文档，统计数量，然后输出一个只包含指定字段的文档。
从内部实现来看，$count 等价于先执行 { $group: { _id: null, count: { $sum: 1 } } }，再用 $project 去掉 _id 并把 count 重命名为用户指定的字段名。需要注意的是，由于 $group 在输入为空时不会产生文档，所以当前面的过滤条件没有命中任何数据时，$count 之后的聚合结果可能为空，而不是返回一个带有 0 的文档。这一点在开发分页接口或统计接口时需要特别处理，不要默认响应中一定存在计数字段。
二、$count 与 $group 加 $sum 的方案对比
在 $count 出现之前，统计文档数量通常要借助 $group 和 $sum 配合完成。传统写法如下：
db.orders.aggregate([
{ $group: { _id: null, total: { $sum: 1 } } },
{ $project: { _id: 0, total: 1 } }
])
而使用 $count 只需要一个阶段：
db.orders.aggregate([
{ $count: "total" }
])
两种方式在只做总数统计时结果一致，但 $count 更简洁，可读性也更强。如果除了总数外还需要计算总金额、平均金额等多个聚合指标，$group 加 $sum、$avg 就更合适，因为它允许在同一个阶段输出多个聚合值。而 $count 只能输出一个计数字段，无法保留业务字段，也无法同时计算多个聚合指标。
另一个差异体现在应用层解析上。使用 $group 时，没有匹配文档会得到空数组；使用 $count 时也可能得到空结果。两者在空结果行为上并没有本质区别，都需要处理空集情况。不应误以为 $count 会固定返回 { total: 0 }，实际表现与 MongoDB 版本和管道上下文有关，稳妥做法仍然是在代码里对空结果做兜底判断。
三、实际场景：条件过滤、分组后计数与分页统计
先看条件过滤后的统计。假设 orders 集合中有 status 字段，要统计已完成订单数量，可以这样写：
db.orders.aggregate([
{ $match: { status: "completed" } },
{ $count: "completedOrders" }
])
这段管道先通过 $match 筛选出已完成订单，再把剩余文档数量写入 completedOrders 字段。因为 $match 可以利用 status 字段上的索引，计数操作在数据量较大时也能保持较好的响应速度。如果查询条件与索引匹配良好，$count 只需要统计索引条目数量，不必回传完整文档，从而减少磁盘 IO。
另一个常见场景是先分组去重后再计数。例如统计有过购买行为的独立用户数，可以先按用户 ID 分组，再对分组结果执行 $count：
db.orders.aggregate([
{ $group: { _id: "$userId" } },
{ $count: "activeUsers" }
])
这里 $group 去重了 userId，每个用户只产生一个分组文档，$count 统计的是分组数量。如果不加 $count，就需要在应用端获取数组后再取长度，既多一步处理，也会把大量分组 _id 传到客户端，造成不必要的内存和带宽消耗。加入 $count 后，数据库端只返回一个计数字段，结果更加精简。
分页查询通常需要同时返回总数和当前页数据。单次聚合中可以用 $facet 分支来实现：一个分支统计过滤结果总数，另一个分支做排序、跳过和限制。
db.orders.aggregate([
{ $match: { status: "completed" } },
{ $facet: {
total: [
{ $count: "count" }
],
list: [
{ $sort: { createdAt: -1 } },
{ $skip: 0 },
{ $limit: 20 }
]
}}
])
执行后返回值结构大致为 { total: [ { count: 1320 } ], list: [ ... ] }。$count 被放在 total 分支的数组中，因此返回的 total 是一个包含一个文档的数组，应用层取 total[0].count 就能拿到总数。这种写法在一次请求中完成计数和数据提取，可以减少网络往返。不过对于超大结果集而言，排序和跳过仍然需要消耗资源，必要时可以拆成两个独立请求来优化性能。
四、常见误区与优化建议
第一个误区是把 $count 放在错误位置。比如想统计原始集合总数，却先写了 $limit 再写 $count，结果只会得到限制后的文档数。正确顺序是先 $match 过滤，再根据需求执行 $sort、$skip、$limit，而 $count 通常放在这些限制阶段之前，或者放在 $facet 的独立分支里。如果确实需要对分页后的结果计数，才可以把 $count 放在 $limit 之后，但此时得到的已经不是全局总数。
第二个误区是忽略字段覆盖。聚合管道中，$count 的输出只包含一个指定字段，此前阶段产生的 _id、业务字段都会被丢弃。如果后续还有阶段试图引用原字段，会报错或得到空值。因此 $count 通常出现在管道末尾，即使放在中间，也要确保后续阶段不再依赖原始字段。
第三个误区是空结果处理不完善。前面讲过，当 $match 没有命中任何文档时，$count 可能不会返回 { count: 0 }，而是返回空结果。因此接口不能直接写 result.count，需要先判断 result 是否为空数组，或者在使用 $facet 时检查 total 数组长度。对 Java、Node.js、Python 等驱动来说，解析聚合游标时也要注意空游标和无文档返回的差异。
性能方面，$count 本身只做计数，不涉及文档内容的读取和排序，开销相对较低。为了让计数更快，可以在 $match 涉及的字段上建立合适的索引。例如按状态统计订单数时，给 status 字段加单字段索引；如果经常按状态和时间范围统计，可以建立复合索引 { status: 1, createdAt: -1 }。这样聚合引擎能够通过索引快速定位并统计，不必扫描整个集合。开发环境中数据量小看不出差异，一旦集合达到百万级以上，索引的作用会非常明显。
MongoDB聚合管道$count文档计数修改时间：2026-09-25 09:28:48