$graphlookup查组织树易超时因未限制递归：需设maxdepth、restrictsearchwithmatch、正确配置connectfromfield/connecttofield，并为parent建索引；推荐物化路径+ancestors数组+折叠展示三重优化。
直接用 $graphLookup 查组织架构树，90% 的场景会卡在首屏或超时——不是 MongoDB 不行，而是你没切断递归路径。
为什么 $graphLookup 在组织树里容易崩
组织架构天然深度大（5–10 层常见）、节点多（上千人）、变动频繁（调岗、汇报线调整），而 $graphLookup 默认不设限：maxDepth=100，restrictSearchWithMatch 为空，connectFromField 和 connectToField 方向写反，三者任一出错就会触发内存溢出或全表扫描。
- 查“张三下属所有部门”，实际要从张三的
_id出发，匹配其他文档的parent字段值 —— 所以必须设connectFromField: "_id"，connectToField: "parent"（注意方向！） - 不加
restrictSearchWithMatch: { status: "active" }，已离职、冻结、待审批节点全参与递归，中间结果暴涨数倍 - 没给
parent字段建索引，$graphLookup内部每次匹配都COLLSCAN，1000 个节点查 5 层，实际扫描量是 O(n⁵)
用物化路径替代递归查询
把路径存成字符串（如 "org|hr|recruit|2026"），用 ^ 开头的正则查子树，毫秒级响应，且完全绕过聚合阶段开销。
- 插入/更新时计算并固化路径：
path字段统一用|分隔，开头无分隔符，结尾不带|，全部小写 + trim 空格 - 必须建
{ path: 1 }索引，否则{ path: { $regex: "^org\|hr\|" } }退化为全表扫描（注意双反斜杠转义） - 禁止用
.或/做分隔符 ——.会被 MongoDB 解析为嵌套字段，/在 URL 或驱动里易被误转义 - 路径深度建议 ≤ 8 层；超过后字符串变长、索引效率下降，且业务上极少需要查到第 12 级汇报线
写入时同步维护祖先数组
物化路径查得快，但查“谁是我的上级”或“我属于哪些部门”仍需反向解析；加一个 ancestors 数组字段，写入时直接存 ["org", "hr", "recruit"]，查祖节点就变成简单 $in 查询。
- 更新员工汇报关系时，原子操作一次性重算
path和ancestors，避免读写不一致 -
ancestors数组要建{ ancestors: 1 }索引，支持{ ancestors: "hr" }这类快速定位 - 别把
ancestors当唯一依据 —— 它和parent字段必须保持逻辑一致，应用层写入前校验环路（比如 A 的祖先含 A 自身）
折叠展示优先用子集模式
首页只显示“直属下级 + 下级的直属下级”，根本不需要整棵树 —— 预存 directSubs 和 subsOfSubs 两个数组字段，查首页就是普通 find({ _id: "zhangsan" })，0 聚合阶段。
- 新员工入职或调岗时，用
$push+$slice更新父节点：{ $push: { directSubs: { $each: [newEmp], $slice: -50 } } } - 数组长度硬限制（如最多 50 人），避免 BSON 超 16MB；超出部分走“查看更多”再触发
$graphLookup或分页拉取 -
directSubs字段只存_id和关键字段（姓名、职级、头像），不嵌套完整文档，减少传输体积
真正难的不是选哪种模型，而是写入路径是否严格校验环路、路径是否统一标准化、索引是否覆盖所有高频查询字段——这三件事漏掉任何一项，再好的设计都会在上线后某次全员调岗时崩掉。
