使用Mongoose查询populate关联子属性时始终返回空数组的问题

失效核心原因 #

• Mongoose的查询执行流是固定不可逆的：第一步先执行find()的查询条件，从business集合捞取符合要求的原始文档；第二步才会对捞到的文档，逐个取createdBy里存的ObjectId，去user集合查对应文档做填充。populate的动作发生在find筛选完成之后，根本不可能把动态拼出来的用户字段反过来作为find的筛选依据。
• 你看到的createdBy字段嵌套了完整用户信息的文档，根本不是数据库里真实存储的结构，那是populate运行完成之后，临时组装出来的查询返回结果。
• 你定义的business Schema里createdBy是关联user集合的ObjectId类型，数据库里真实存的business文档中，createdBy只是一个单独的用户ID字符串值，根本不存在.name这个嵌套属性。所以用createdBy.name做find查询条件时，匹配路径完全不存在，自然永远返回空结果。
• 公开教程的写法之所以能跑通，是因为这些教程的示例大多用的是内嵌子文档的Schema结构，不是populate关联ObjectId的结构——这种结构下用户信息真的存在business文档里，嵌套字段查询自然能生效。但把这套写法直接套到populate关联场景，就会完全失效。

正确实现方案 #

方案1：populate阶段增加关联匹配规则 #

利用populate的内置match参数，在关联查询用户时增加姓名匹配规则，最后再过滤掉关联用户不匹配的文档。

business.find({})
  .populate({
    path: 'createdBy',
    // 对关联查询的user集合加匹配条件
    match: { name: { $regex: "steve", $options: 'i' } }
  })
  // 过滤掉关联用户不匹配、createdBy被填充为null的文档
  .then(docs => docs.filter(doc => doc.createdBy !== null))

注意：这个方案是先全量捞出所有business文档，再做关联匹配，数据量大时性能较差，仅适合小数据量场景。

方案2：反向查询关联集合匹配ID（推荐生产环境使用） #

把查询逻辑反过来，先从用户集合拿到符合姓名条件的ID列表，再用ID列表查询business，完全走数据库原生索引，性能最优：

// 第一步：拿到所有姓名匹配的用户ID
const matchedUserIds = await User.find(
  { name: { $regex: "steve", $options: 'i' } }
).distinct('_id')

// 第二步：用ID列表查询关联的business文档，再做populate
const result = await business.find({ createdBy: { $in: matchedUserIds } })
  .populate('createdBy')

方案3：修改Schema为内嵌子文档结构 #

如果确实需要直接用createdBy.name这类嵌套字段做find查询，需要把Schema里的createdBy从关联ObjectId类型改为内嵌子文档类型，直接把用户信息存在business文档内部。但这种方式会带来大量数据冗余，用户信息更新时需要同步修改所有关联的business文档，维护成本很高，非特殊场景不推荐。

内容的提问来源于stack exchange，提问作者Kaki Master Of Time