$graphlookup是唯一原生支持多级递归查询的聚合阶段，但需正确设置connectfromfield:"parent"与connecttofield:"_id"、限制maxdepth、添加restrictsearchwithmatch过滤、为parent字段建索引，并在应用层处理环路校验和树形组装。
$graphLookup 是唯一能原生支持多级递归查询的聚合阶段，但直接用它查分类树很容易爆内存或查不出结果——关键在字段方向、深度控制和环路防护。
connectFromField 和 connectToField 方向别反
这是最常踩的坑：查“某节点的所有子孙”，意味着要从该节点出发，顺着 parent 字段往上找父节点的父节点……不对，是往下找子节点。所以实际路径是：_id → 子文档的 parent 字段值匹配另一个文档的 _id。
因此必须设成：
-
connectFromField: "parent"（当前文档的 parent 值，作为“起点”） -
connectToField: "_id"（去匹配其他文档的 _id，作为“目标”） - 反着写（
connectFromField: "_id",connectToField: "parent"）就变成查祖先了，而且大概率为空
maxDepth 和 restrictSearchWithMatch 不加必翻车
默认 $graphLookup 深度上限是 100，但真实业务中 4–6 级已足够；不设 maxDepth，小数据看着正常，一上量就触发 "Exceeded memory limit for $graphLookup"。
同时，中间过程若包含大量 inactive 或 deleted 文档，内存压力会指数上升。务必加过滤：
- 显式指定
maxDepth: 5（按你业务最大嵌套层级设，别留“余量”） - 用
restrictSearchWithMatch: { status: "active" }提前筛掉无效节点 - 避免在
as字段里直接写"children"——它返回的是扁平数组，不是嵌套对象，后续还得靠代码做树形重组
防循环引用得靠应用层校验，MongoDB 不管
用户拖拽把节点 A 移到自己子孙 B 下面，形成 A → B → A 环，$graphLookup 会直接报错 "Cycle detected in graph"，且无法恢复。
MongoDB 不提供环检测能力，这事必须后端兜底：
- 移动前，先跑一次反向
$graphLookup：从目标父节点出发，用connectFromField: "_id",connectToField: "parent"查它的所有祖先 - 检查结果里是否包含当前要移动的节点自身 ID
- 绝不能信任前端传来的
parent值直插入库，必须校验通过才更新
索引没建好，$graphLookup 性能断崖下跌
$graphLookup 内部要高频匹配 connectToField 字段（通常是 _id），但如果 connectFromField（如 parent）没索引，每次查找都扫全表。
执行这条命令建索引，否则查子节点慢到不可用：
db.categories.createIndex({ parent: 1 })
注意：
- 如果用字符串 ID（如
"cat-123"），parent字段也必须是字符串，索引类型要一致 - 别用
"null"或空字符串表示根节点，统一用null或ObjectId("000000000000000000000000") -
$graphLookup返回的是扁平结果，真正要渲染树形结构，还是得在应用层分组、递归组装——这点容易被忽略，以为查出来就能直接用
