简而言之，当你的数组包含多个元素，并且希望依据特定条件筛选出其中一部分时，使用 $filter 是最清晰高效的做法。它不会破坏原有文档结构，也不会像 $unwind 那样产生额外的运算开销，筛选结果依然保持为数组格式，方便后续继续处理。

在 $project 阶段利用 $filter 对数组进行过滤，是目前最轻量且可控性最高的方法。它不会改动文档结构，不会触发数组展开，也无需引入额外的 $unwind 开销。简而言之，当你的数组包含多个元素，并且希望依据特定条件筛选出其中一部分时，使用 $filter 是最清晰高效的做法。

为什么不应直接用 $elemMatch 投影？

你可能会问：为什么不用看似更简洁的 $elemMatch 投影呢？但 $elemMatch 存在一个关键陷阱——它仅返回数组中「第一个」匹配的元素，即使有 5 个子文档符合条件，它也只会输出一个。这本质上是一个「匹配并截断」的操作，而非真正的「过滤并保留」。如果后续需要遍历所有匹配项或统计匹配数量，$elemMatch 会掩盖数据的真实分布。例如，写 { "items": { "$elemMatch": { "price": { "$gt": 100 } } } } 后，结果中的 items 字段永远是一个单独的对象，而不是数组。因此，使用不当会带来严重偏差。

$filter 必须与 $project 配合使用

需注意，$filter 属于聚合操作符，不能直接出现在 find() 的 projection 参数中。它只能嵌套在聚合管道的 $project、$addFields 或其他支持表达式的阶段内。错误写法如 db.collection.find({}, { items: { $filter: { ... } } }) 会引发 unknown operator: $filter 错误。正确的做法是 db.collection.aggregate([ { $project: { items: { $filter: { input: "$items", cond: { $gt: ["$$this.price", 100] } } } } } ])。其中 $$this 是默认变量名，也可以显式指定 as: "item"，然后用 $$item.price 来引用，可读性更强。

$filter 的 input 字段必须为数组，否则会报错

这是一个容易踩坑的地方。如果字段不存在、值为 null，或者值为字符串、数字等非数组类型，$filter 会直接中断整个 pipeline 并抛出错误，不会静默跳过。安全的做法是先使用 $ifNull 或 $cond 兜底，例如 input: { $ifNull: ["$items", []] }。调试时可用 $type 检查，确认返回类型为 "array"。另外，MongoDB 6.0+ 新增了 limit 参数，如果你只希望获取前 3 个匹配项，可以写成 limit: 3。

性能与兼容性注意事项

$filter 本身不会走索引，它是在内存中对已加载的数组进行遍历。因此，影响性能的关键不在于 $filter 本身有多慢，而在于有多少文档进入了 pipeline。最重要的步骤是：务必在 $match 阶段先缩小文档范围，例如增加 { "items.price": { "$gt": 100 } } 条件，这样能借助索引过滤，大幅减少后续管道处理的文档数量。

兼容性方面，$filter 在 MongoDB Community 4.2+、Atlas 所有版本、Enterprise 4.0+ 中均可使用，已覆盖绝大多数生产环境，无需特意升级到最新版。此外，不要在 $filter 的 cond 中调用复杂函数（如 $regex）处理大量文本，这会显著拖慢响应速度。

最后，有一个容易被忽视的点：$filter 表达式的作用域仅限于当前数组字段，无法访问同级的其他字段，更无法跨文档引用。如果业务需要根据父文档的动态状态来决定子数组的筛选条件，就需要改用 $map + $cond 的组合，或提前将逻辑下沉到应用层处理。