用 path 字段做前缀匹配，别存父子 id 链表：应冗余存储完整路径（如 "/system/user/role/"）和 level，配合正则查询；需同步维护 ancestors 数组以支持面包屑和祖先判断；慎用 $graphlookup，优先预计算；务必建 tenant_id+path 或 level+status 等复合索引。
用 path 字段做前缀匹配，别存父子 ID 链表
树形菜单最常踩的坑是照搬关系型数据库思维，用 parent_id + 递归查子节点——MongoDB 没原生递归查询，每次展开一级菜单都要 N 次 round-trip，前端卡顿明显。
真正高效的做法是冗余存储完整路径，比如 "path": "/system/user/role"，再加一个 level 字段标层级。这样查「系统」下所有二级菜单就是一条 find({ path: { $regex: "^/system/[^/]+/$" } })。
-
path值统一以/开头、结尾（如/a/b/c/），避免/ab/c误匹配/a/b/c - 插入新节点时，必须拼接父级
path+ 自身 slug，不能靠应用层“查父节点再拼”，否则并发写入可能不一致 - 更新节点名或移动位置时，要批量更新所有后代的
path字段，建议用updateMany加正则条件，别单条查改
需要动态折叠/展开时，加 ancestors 数组字段
纯 path 字符串能快速查某一层，但没法直接拿到「从根到当前节点的全路径」用于面包屑，也不能高效判断 A 是否是 B 的祖先——这时候就得用数组存祖先 ID 或 slug。
例如菜单项 { _id: "role", ancestors: ["system", "user"] }，查「role」的所有上级菜单就只需 find({ _id: { $in: doc.ancestors } })，一次查完。
- 数组内容推荐存
_id而非 name，避免重命名后数据不一致 - 插入/移动节点时，
ancestors必须和path同步更新，漏掉一个就导致面包屑断链或权限校验出错 - 如果菜单层级很深（>10 层），
ancestors数组会变长，但 MongoDB 对数组索引支持好，加个createIndex({ ancestors: 1 })就能走索引
图查询需求强？用 $graphLookup 但小心性能陷阱
真有“找某个菜单的所有下游权限节点”“查两个菜单最近公共祖先”这类图式需求，$graphLookup 是唯一原生方案，但它不是银弹。
它本质是服务端循环聚合，深度大或匹配节点多时极易超时或打爆内存。生产环境必须加严格限制。
- 务必设置
maxDepth: 3（菜单一般不超过 4 层），不设等于放任无限遍历 - 用
restrictSearchWithMatch过滤中间节点，比如只允许查status: "active"的菜单，别让聚合扫全表 - 别在高频接口（如用户登录后拉菜单）里用
$graphLookup，提前算好路径/祖先存到文档里更稳
组合路径字段要建复合索引，别只靠单字段
path 字段单独建索引没用——正则查询 ^/a/b/ 只能用上前缀部分，而 ancestors 数组查询必须配合其他条件才高效。
实际常用组合是「状态 + 路径前缀」或「租户 + 路径」，比如 SaaS 多租户场景：createIndex({ tenant_id: 1, path: 1 })，这样按租户查菜单时，path 正则能命中索引范围扫描。
- 别忘了
level字段，按层级筛选（如只显示一级菜单）时，{ level: 1, status: "enabled" }复合索引比单字段快得多 - 测试索引是否生效：用
explain("executionStats")看nReturned和totalDocsExamined是否接近，差太多说明没走对索引
路径设计看着简单，但一旦菜单要支持拖拽排序、多语言、租户隔离、实时权限收敛，path 和 ancestors 的更新时机、事务边界、索引覆盖，每个点都容易漏掉一两个条件，上线后才暴露。
