结论：用物化路径模式配合path字段单字段索引是MongoDB实现无限层级菜单最实用、查询最可控的方案；因其可索引、可正则、无歧义，避免了$graphLookup全量遍历和嵌套文档维护难的问题。
直接说结论：用 物化路径 模式，配合 path 字段上的单字段索引，是 MongoDB 里实现无限层级菜单最实用、查询最可控的方案。别硬套嵌套文档或 $graphLookup——前者写入难维护，后者查一次树就全扫一遍，性能不可控。
为什么不用 $graphLookup 查无限层级菜单？
它确实能递归查子节点，但实际用起来有几个硬伤：
-
$graphLookup必须指定from集合，且不能跨库；菜单通常和用户、权限等混在一个库，但你没法让它去查另一个库的菜单集合 - 每次查询都从根开始遍历，哪怕只想要第三级子菜单，它也得把第一、二级全捞出来再过滤，
maxDepth只是截断，不跳过中间层 - 无法利用索引加速——
$graphLookup是内存遍历，path字段上建了索引也没用 - 如果菜单节点带状态（比如
is_hidden: true），restrictSearchWithMatch会进一步拖慢速度，且无法提前剪枝
物化路径怎么存、怎么查才不踩坑？
核心是让 path 字段可索引、可正则、无歧义。示例数据如下：
db.menus.insertMany([
{ _id: "home", name: "首页", path: ",home," },
{ _id: "system", name: "系统管理", path: ",system," },
{ _id: "user", name: "用户管理", path: ",system,user," },
{ _id: "role", name: "角色管理", path: ",system,role," },
{ _id: "menu", name: "菜单管理", path: ",system,menu," }
])
关键点：
- 首尾都加逗号，避免
/,sys/匹配到system和systematic -
path值是完整祖先路径，不是相对路径，这样^,system,才能精准匹配整个子树 - 插入前必须确保父节点已存在，否则
path构造会出错——这不是数据库约束，得在应用层校验 - 更新节点位置时，要批量更新所有后代的
path字段，不能只改当前节点
哪些查询能走索引？哪些不能？
path 上建索引：db.menus.createIndex({ path: 1 })，但效果取决于查询写法：
- 能高效走索引：查询以某节点为根的全部后代，例如
{ path: /^,system,/ }—— B-tree 可以范围扫描前缀 - 能部分走索引：模糊查中间某段，例如
{ path: /,role,/ }—— 索引仍需扫描大量键，但比全表快（尤其当索引大小 - 完全不走索引：用
$regex不带锚点，例如{ path: { $regex: "role" } }，或用$text—— 这两类都不适合路径结构 - 注意：MongoDB 不支持对正则表达式做索引优化，所以
/^,system,.*$/和/^,system,/效果一样，但后者更清晰、易读
真正容易被忽略的是路径更新成本：移动一个中间节点（比如把 role 从 system 下挪到 security 下），所有 role 的后代都要重写 path。如果菜单变更不频繁，这没问题；如果需要实时拖拽排序，就得加队列或版本控制，不能裸写 updateMany。
