MongoDB的文档模型允许我们在一个文档中嵌套复杂的数组结构，比如订单文档中的商品列表、文章文档中的评论列表、用户文档中的多地址信息。实际业务中经常遇到这样的需求：筛选出数组中满足特定条件的所有元素，同时保留父文档的其他字段。这个看似简单的需求，在聚合框架中其实有多种实现方式，选择不当可能导致性能问题或结果不符合预期。本文将系统讲解几种核心方案及其取舍。
使用 $filter 操作符直接过滤数组
当需求是保留文档整体结构、仅剔除数组中不匹配的元素时，$filter 是最直接、最优雅的选择。它在聚合管道中对数组进行逐元素判断，返回所有满足条件的元素组成的新数组，父文档的其他字段原样保留。这种方式不会改变文档的数量，一个输入文档对应一个输出文档，非常适合列表页展示的场景。
假设有一个订单集合，orders 数组中存放着该用户的多笔订单，我们想查询所有金额大于 500 且状态为已完成的订单，同时保留用户名和注册时间等字段。聚合语句可以这样写：
db.users.aggregate([
{
$project: {
name: 1,
createdAt: 1,
// 只保留满足条件的订单元素
matchedOrders: {
$filter: {
input: "$orders",
as: "order",
cond: {
$and: [
{ $gt: ["$$order.amount", 500] },
{ $eq: ["$$order.status", "completed"] }
]
}
}
}
}
}
])注意几个细节：input 指定要过滤的数组字段，as 定义循环变量的名称，在 cond 中通过双美元符号引用这个变量。如果希望结果中只保留有匹配项的文档，可以在后面追加一个 $match 阶段过滤掉 matchedOrders 为空数组的文档。$filter 的优势在于语义清晰、不会产生文档膨胀，缺点是无法直接利用数组内字段的索引，过滤发生在内存中。
使用 $unwind 展开数组后再匹配重组
第二种思路是先把数组展开成多条文档，用 $match 精确筛选，再用 $group 重新组合回父文档。这种方式代码量稍多，但优势明显：展开后的 $match 条件如果命中了多键索引，可以大幅减少需要处理的数据量；此外它还支持对匹配元素做计数、求和等统计操作，这是 $filter 做不到的。
同样的需求用展开方式实现如下：
db.users.aggregate([
{ $unwind: "$orders" },
{
$match: {
"orders.amount": { $gt: 500 },
"orders.status": "completed"
}
},
{
$group: {
_id: "$_id",
name: { $first: "$name" },
createdAt: { $first: "$createdAt" },
matchedOrders: { $push: "$orders" }
}
}
])这里 $unwind 把每个订单元素拆成独立文档，$match 利用索引只保留符合条件的行，$group 按原始文档 _id 重新聚合，用 $first 取回父文档字段，用 $push 把匹配的元素重新收集成数组。如果还需要统计匹配数量，只需在 $group 中加一行 count: { $sum: 1 } 即可，灵活性远高于 $filter。
这种写法的代价是文档数量先膨胀后收缩，当数组元素极多时，$unwind 产生的中间文档会占用较多内存和管道传输开销。MongoDB 默认单条聚合管道内存限制为 100MB，数据量大时需要注意，必要时可以加 allowDiskUse 选项允许落盘。
查找数组中的单个匹配元素：$elemMatch 与位置投影
如果需求只要求返回数组中第一个匹配的元素，其实不需要聚合框架，普通 find 查询配合 $elemMatch 投影就能搞定，性能也更好：
db.users.find(
{ orders: { $elemMatch: { amount: { $gt: 500 }, status: "completed" } } },
{ name: 1, "orders.$": 1 }
)$elemMatch 在查询条件中表示数组中至少存在一个元素同时满足所有给定条件，而 "orders.$" 位置投影则只返回第一个匹配的元素。这种方式可以直接利用多键索引，是单元素匹配场景的首选。要理解一个容易混淆的概念：$elemMatch 出现在查询条件部分和投影部分含义不同，条件部分用于匹配文档，投影部分用于裁剪返回的数组内容，两者经常配合使用。
性能优化与方案选择建议
三种方案如何选择？可以参考以下对比：
| 方案 | 适用场景 | 能否利用索引 | 文档数量变化 |
|---|---|---|---|
| $filter | 保留结构，提取全部匹配项 | 否 | 一对一 |
| $unwind + $group | 大数据量、需统计、需排序 | 是 | 先膨胀后收缩 |
| $elemMatch + 位置投影 | 只需要第一个匹配元素 | 是 | 一对一 |
实践中有几点建议值得注意。第一，如果嵌套数组字段会被频繁按条件查询，应该为其建立多键索引，例如 db.users.createIndex({ "orders.status": 1, "orders.amount": 1 })，这样 $unwind 后的 $match 才能真正提速。第二，管道阶段的顺序至关重要，尽量把 $match 放在 $unwind 之前或紧随其后，让索引过滤尽早发生，减少后续阶段的处理量。第三，如果数组嵌套层级很深，比如数组元素的子字段还是数组，$filter 可以嵌套使用，但可读性会明显下降，此时考虑在建模阶段适当反范式化，或者将子数组拆分为独立集合可能更合理。
总之，$filter 适合轻量的结构化过滤，$unwind 加 $group 适合需要索引加速和统计分析的重型场景，$elemMatch 则是单元素提取的最佳选择。理解三者的底层执行逻辑，结合数据规模和索引设计做取舍，才能让聚合查询既精准又高效。
MongoDB聚合查询$filter操作符嵌套数组匹配修改时间：2026-09-01 15:29:21