MongoDB $lookup内嵌$search后store_details为空数组问题排查

核心问题1：$search阶段的执行顺序错误 #

Atlas Search的$search必须作为$lookup内部pipeline的第一个阶段。如果你的pipeline里先写了$match匹配关联ID，再放$search，会导致搜索逻辑失效，最终返回空数组。

错误写法示例：

{
  $lookup: {
    from: "location_view_for_search",
    let: { id_str: { $toString: "$stores.id" } },
    pipeline: [
      // 错误：先匹配ID再执行搜索，$search无法正常工作
      { $match: { $expr: { $eq: ["$location_number", "$$id_str"] } } },
      { $search: { autocomplete: { query: "xxx", path: "location_number" } } }
    ],
    as: "store_details"
  }
}

正确顺序：先执行$search，再用$match过滤关联记录：

{
  $lookup: {
    from: "location_view_for_search",
    let: { id_str: { $toString: "$stores.id" } },
    pipeline: [
      // 优先执行搜索
      { $search: { autocomplete: { query: "xxx", path: "location_number" } } },
      // 再过滤与当前store_group匹配的结果
      { $match: { $expr: { $eq: ["$location_number", "$$id_str"] } } }
    ],
    as: "store_details"
  }
}

核心问题2：$search中引用外部变量的限制 #

不要尝试在$search的查询条件里直接引用$$id_str（来自外层store_group的变量），Atlas Search的执行机制可能无法正确解析这类外部变量。必须把关联匹配放在$search之后的$match阶段，通过$expr关联变量。

额外排查点 #

• 确认location_view_for_search中的location_number和转后的id_str完全一致：字符串匹配是严格区分的，要检查是否有多余空格、大小写差异等问题。
• 单独验证关联逻辑：直接在视图上执行db.location_view_for_search.aggregate([{$search:...}, {$match: {location_number: "转后的ID字符串"}}])，确认能返回预期结果。

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