MongoDB聚合中使用$lookup时如何按属性查询bulk子文档？

• 你编写的$match: { 'bulk.name': 'xyz' }无法生效，本质是匹配阶段的位置不符合聚合数据流逻辑
• 聚合流程最开头的$match处理的是原始业务集合的文档，此时还没有经过$lookup关联bulks集合，原始文档里根本不存在关联后的bulk字段，自然无法匹配到任何结果。
• 即使把这个$match移到$lookup之后，此时生成的bulk是一个存储关联文档的数组字段，如果后续没有经过拆包就直接匹配，也容易出现路径解析失效的问题。

1. 梳理当前聚合的完整数据流顺序：
   原始数据按用户维度匹配 -> 两轮分组统计不同状态的计数 -> 通过$lookup关联bulks集合得到带bulk数组的中间结果 -> 通过$replaceRoot把单条bulk文档合并到文档根节点 -> 通过$project删除冗余的bulk数组字段
2. 针对bulk文档属性的过滤，必须放在对应字段已经存在于当前文档结构的位置执行，绝不能前置到关联操作之前：
   • 方案一（性能最优，推荐）：在$replaceRoot阶段之后、$project阶段之前插入匹配逻辑
     因为$replaceRoot已经把bulk文档的所有属性直接合并到文档根层级了，此时不需要带bulk.字段前缀，直接写属性路径即可。例如要匹配bulk文档中name等于xyz的记录：

     // 插入位置：$replaceRoot 阶段的下方
     { $match: { name: 'xyz' } }
     

   • 方案二（代码改动最小）：在$lookup阶段之后、$replaceRoot阶段之前插入匹配逻辑
     此时bulk是数组结构，MongoDB原生支持对数组内文档的属性路径匹配，你最初的写法可以正常生效：

     // 插入位置：$lookup 阶段的下方
     { $match: { 'bulk.name': 'xyz' } }
     

3. 避坑提示：
   • 不要把bulk属性的匹配放在最后一个$project阶段之后，因为你在$project中已经将bulk字段从文档结构中删除了，此时对应属性已经不存在，匹配会直接失效。
   • 匹配逻辑的位置越靠近数据关联操作，后续阶段需要处理的无效数据越少，聚合运行性能越高。

内容的提问来源于stack exchange，提问作者amit s