$graphLookup查不到子节点主因是parent_id字段类型不一致，如ObjectId与字符串混用；startWith未匹配起始文档、未设maxDepth或未用let注入上下文也会导致异常。
为什么 $graphLookup 查不到子节点？
最常见的原因是 from 集合里文档的 parent_id 字段值类型不一致——比如有的存的是 ObjectId，有的存的是字符串 ID。MongoDB 不做隐式转换，"123" 和 ObjectId("123") 被视为完全不同的值，导致递归匹配中断。
实操建议：
- 用
db.collection.find({ parent_id: { $type: "string" } })检查字段类型是否混用 - 统一用
ObjectId：确保插入时用new ObjectId("...")，而不是字符串 - 如果必须兼容字符串 ID，可在
connectFromField或connectToField侧做类型转换（需 MongoDB 4.4+），例如：{ $toString: "$parent_id" }作为connectFromField的表达式（注意：这要求目标字段也转成字符串）
$graphLookup 返回结果为空数组？
不是数据不存在，而是起始点没匹配上 startWith 表达式。这个字段必须精确命中集合中某条文档的某个字段值，否则整个递归直接跳过，返回空数组。
常见错误场景：
-
startWith写成字符串字面量，比如"$id"（少了一个$符号，实际应为"$$id"或"$field_name"） - 聚合管道上游没传入变量，却在
startWith里引用了$$id—— 此时$$id是 undefined，匹配失败 - 被查找的字段名拼写错误，比如文档是
_id，但startWith写成了"$id"
验证方法：单独运行 db.collection.findOne({ _id: ObjectId("...") }) 确认起始文档存在，再检查 startWith 表达式是否能正确提取该文档的关联字段值。
如何限制递归深度避免性能爆炸？
maxDepth 不是可选参数，是必须设的保命开关。不设的话，循环引用（比如 A→B→C→A）或深层树（500 层）会让查询卡死、OOM 或触发服务器超时。
实操要点：
-
maxDepth: 0表示只查直接子节点（1 层），maxDepth: 2表示最多查到孙节点（3 层） - 配合
depthField使用，能知道每条结果来自第几层，方便前端做缩进或折叠逻辑 - 生产环境建议从
maxDepth: 3开始试，再根据业务最大嵌套深度微调；超过 6 层基本要考虑前端分页或懒加载替代方案
示例片段：
{
$graphLookup: {
from: "categories",
startWith: "$_id",
connectFromField: "_id",
connectToField: "parent_id",
as: "children",
maxDepth: 2,
depthField: "level"
}
}
为什么子节点里没有父节点字段？
$graphLookup 默认只返回匹配到的文档完整副本，不会自动带上“当前层级关系”信息。比如你查一个节点的所有后代，结果里每个子文档还是只有自己的 _id 和 parent_id，没法直接看出它是第几级、谁是它的直系父节点。
解决办法是用 let + pipeline 在子查询里注入上下文：
- 在
let中定义变量（如{ parent: "$_id" }） - 在
pipeline的$addFields阶段把$$parent加进去，这样每个子节点都带上了“它被哪个父节点拉出来的”信息 - 注意：此时
as字段里的数组元素结构会变，需适配后续处理逻辑
典型写法：
{
$graphLookup: {
from: "menus",
startWith: "$_id",
connectFromField: "_id",
connectToField: "parent_id",
as: "tree",
let: { rootId: "$_id" },
pipeline: [
{ $addFields: { rootId: "$$rootId" } }
]
}
}
真正难的不是语法，是理清“谁在驱动递归”和“谁在接收结果”。字段类型、起始点表达式、深度控制、上下文注入——四者漏一，查出来的就不是树，是一团乱麻。
