MongoDB本身不原生支持递归查询，$graphLookup是唯一能模拟递归的聚合阶段，但需严格设定startWith、connectFromField、connectToField等参数，且受内存限制、深度控制及方向性约束，无法替代SQL的WITH RECURSIVE。
直接说结论：MongoDB 本身不原生支持递归查询，聚合管道无法直接查出任意深度的上下级组织树，必须靠应用层循环、预计算路径（如 ancestors: ["A", "B", "C"]）或 $graphLookup 配合严格限制条件来逼近。
$graphLookup 是唯一能“模拟递归”的聚合阶段
$graphLookup 用于图遍历，适合处理具有父子关系的组织结构（如 parent_id 字段），但它不是 SQL 的 WITH RECURSIVE，有硬性约束：
- 必须指定明确的起始点（
startWith），不能“查整个树” - 必须定义
connectFromField和connectToField（例如"parent_id"→"_id"） - 默认只展开一层；要查多层，得用
depthField+ 后续$unwind+$group拼接，但深度不可动态扩展 - 不支持反向查上级（即从子查父），除非你把
connectFromField设为"_id"、connectToField设为"parent_id"，并设startWith为子节点 ID
常见错误现象：maxDepth 被忽略、结果为空、返回重复文档、内存超限（尤其未加 $match 过滤时）
实操建议：
- 组织集合必须有明确的引用字段，比如
orgs = { _id: "C", name: "研发三组", parent_id: "B" } - 查某部门的所有下级（含子孙）：
[{ $graphLookup: { from: "orgs", startWith: "$_id", connectFromField: "_id", connectToField: "parent_id", as: "children", depthField: "level" } }] - 若要查“上级链”（如 C → B → A），需把方向反过来：
startWith: "$parent_id"，且确保根节点的parent_id为null或缺失，否则会断链 - 务必在
$graphLookup前加$match，否则全表扫描，性能崩盘
为什么不用 $lookup + 多次 $unwind？
有人试图用多个 $lookup 手动拼 3 层（部门→上级→上上级），但问题明显：
- 层级写死，无法适配“有的组织只有 2 级、有的有 5 级”
- 每次
$lookup返回数组，$unwind后数据行数爆炸（笛卡尔积风险） - 代码臃肿，可读性差，维护成本高
- MongoDB 4.4+ 虽支持
pipeline参数进$lookup，但仍不解决递归本质问题
真正落地的推荐做法
生产环境别赌 $graphLookup 能覆盖所有场景。更稳的方案是：
- 写入时预存路径：在组织文档里加字段
path: ["A", "B", "C"]，查“B 的所有下级”就用{ path: { $regex: "^B/" } }，配合索引极快 - 用应用层递归：先查出直接下级，再批量查它们的下级，控制最大深度（比如 ≤ 6），避免单次聚合过载
- 如果必须用聚合返回完整树，
$graphLookup后一定要跟$addFields+$map清洗level，再$sort保证父子顺序，否则前端渲染错乱 - 注意
allowDiskUse: true—— 深度大、节点多时，$graphLookup很容易突破 100MB 内存限制
真正难的不是写出能跑的聚合语句，而是判断“该不该在这里用聚合”。组织树这类强层级、常更新、需灵活遍历的数据，往往更适合由业务代码驱动，而不是塞进一个聚合管道里硬解。
