$graphlookup可实现自引用层级展开但需配合$map等操作构造嵌套树结构，因其仅返回扁平后代列表；设maxdepth防环路，深度大时宜前端分页懒加载。
用 $graphLookup 实现自引用层级展开
MongoDB 本身不支持递归查询，但 $graphLookup 是唯一能逼近“无限层级树形展开”的原生聚合阶段。它适用于典型的自引用结构：文档中包含 parentId 字段指向同集合内其他文档的 _id。
常见错误是把 startWith 写成字符串字面量（如 "$parentId"），实际必须是表达式："$parentId" 是合法字段路径，"parentId" 是字面字符串，会导致查不到任何子节点。
-
from必须指定为当前集合名（如"categories"），不能省略或写错大小写 -
connectFromField填子节点的父引用字段名（如"parentId"） -
connectToField填父节点的唯一标识字段（通常是"_id"） -
as指定输出数组字段名（如"children"），后续可用$map+$mergeObjects递归注入
为什么不能只靠 $graphLookup 就得到完整树？
$graphLookup 默认只做单次广度优先遍历，返回的是“所有后代扁平列表”，不是嵌套结构。比如根节点 A 查出 [B, C, D, E]，但不会自动组织成 { children: [{ children: [...] }, ...] }。
要真正生成嵌套 JSON，必须配合 $map 和递归式 $let（4.2+）或多次 $addFields 手动“逐层填充”。更现实的做法是：用 $graphLookup 获取全量后代 + 排序，再在应用层（Node.js/Python）按 parentId 构建树——既清晰又可控。
- 聚合内递归构造树在深度 > 5 层时极易触发
Maximum call stack size exceeded（在 JS 表达式里）或超内存 -
$graphLookup的maxDepth是硬限制，设为 10 并不意味着一定能拿到 10 层深的嵌套对象，只是最多遍历 10 跳 - 如果数据存在环（A→B→A），不设
maxDepth可能导致聚合卡死
用 $facet + $map 组装顶层节点与子树
当只需要一级子树（如菜单只展开两级），可以避开递归，用 $facet 分别查根节点和所有子节点，再用 $map 关联：
{
$facet: {
"roots": [{ $match: { parentId: null } }],
"allNodes": [{ $match: {} }]
}
}
接着在后续阶段用 $map 遍历 $roots，对每个根节点用 $filter 从 $allNodes 中挑出直接子节点，再用 $mergeObjects 合并 children 字段。
- 这种写法可读性强，调试方便，且不依赖
$graphLookup的深度限制 - 注意
$filter的条件必须用$$this.parentId === $$root._id这类双美元符号语法，否则变量作用域错乱 - 若子节点数量大（>1000），
$facet会把全量数据加载进内存，可能触发Exceeded memory limit
真实项目中更推荐的折中方案
在 API 层控制树形深度，例如前端请求 /api/categories?depth=2，后端聚合只查两层：
- 第一层：根节点（
parentId: null） - 第二层：所有根节点的直接子节点（
parentId: { $in: [root1._id, root2._id, ...] }） - 第三层起交给前端按需懒加载，避免一次拉取整棵树压垮数据库
真正难处理的不是聚合语法，而是数据一致性——比如 parentId 指向已删除文档，或存在孤儿节点。这类问题不会报错，但树形渲染时突然缺一层，排查起来往往要翻日志比对 ID，而不是改聚合语句。
