MongoDB聚合管道：基于上步ObjectId数组实现同集合二次匹配（免$lookup）

核心判断 #

• 你当前的聚合写法完全基于对管道执行模型的误解：MongoDB聚合是逐阶段的流式处理逻辑，每个阶段仅能接收上一阶段输出的文档集，没有主动扫描整个集合拉取其他文档的能力，除非使用专门的查询类阶段。
• 若完全排除$lookup操作，没有任何单条聚合管道的实现能满足需求。所有原生聚合阶段中，$lookup是唯一能主动从任意集合（包括当前同集合）批量拉取文档、注入管道处理流的查询类阶段；其余阶段（$match/$project/$unwind等）仅能对已进入管道的文档做加工，无法跨范围查询集合中的其他文档。

现有写法的具体问题 #

• 第一处$match执行完成后，管道内仅会保留1条与目标_id匹配的用户文档，后续所有阶段都只能加工这1条文档的内容，根本接触不到集合中存储的其他关联用户文档。
• 第二处$match存在语法错误：$in的匹配右值必须是数组，直接传入字段路径字符串"ids"无法匹配任何有效结果；就算修正语法，$match的匹配范围也仅局限于当前管道中的那1条文档，根本无法对全集合执行$in批量查询。

正确的单条查询实现 #

如果你能接受同集合自连接的$lookup（该方案本质仍是1次数据库请求，相比两次独立查询省掉了Node.js与数据库的两次网络往返，且因为_id是主键索引，查询性能与手动两次查询几乎一致），完整聚合管道如下：

await usersCollection
  .aggregate([
    // 匹配目标用户文档
    { $match: { _id: new ObjectId(userId) } },
    // 同集合自连接，基于connections数组批量匹配关联用户
    {
      $lookup: {
        from: "users",
        localField: "connections",
        foreignField: "_id",
        as: "connectedUsers"
      }
    },
    // 投影仅保留需要的字段
    {
      $project: {
        connectedUsers: {
          username: 1,
          avatar: 1,
          _id: 0
        },
        _id: 0
      }
    }
  ])
  .toArray()

执行后返回文档中的connectedUsers字段，就是仅包含关联用户username、avatar的结果数组，完全匹配需求。

边界说明 #

如果坚持不使用$lookup，不存在单条聚合的替代实现，只能回到两次独立查询的模式。

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