嵌套文档适合读多写少、树结构稳定且层级浅（≤4层）、节点数少的场景，如静态权限菜单；不能无脑用因更新需硬编码路径、受16MB文档限制、并发写易冲突。
没有“优雅”的通用解法，只有匹配场景的合理选型：读多写少用嵌套文档，动态频繁更新用 parent_id 引用 + $graphLookup，高并发或深层级菜单优先冗余 path 字段。
嵌套文档适合什么场景？为什么不能无脑用？
当你确定树结构几乎不改、层级固定（比如后台权限菜单、静态类目表），且深度 ≤ 4、每层节点数 ≤ 10，children 数组嵌套最省事。查整棵树只要一条 findOne()，不用聚合、不建索引、代码干净。
- 插入示例：
db.menus.insertOne({ name: "System", children: [{ name: "Users", children: [{ name: "Roles" }] }] }) - 查询整树：
db.menus.findOne({ name: "System" }) - 更新任意子节点必须用硬编码路径，比如改 Roles 名字得写
$set: { "children.0.children.0.name": "Permissions" }—— 深度一增加，路径就难维护 - 单文档 16MB 限制是隐形天花板：5 层 × 每层 20 个节点 × 平均 1KB/节点 ≈ 3.2MB；但加上字段名、索引键、预留空间，实际撑不到 7 层
- 并发写同一父文档会触发写冲突，
writeConcern再强也救不了——MongoDB 不支持对数组内嵌文档的原子局部更新
parent_id 引用模型下，$graphLookup 怎么写才不出错？
这是动态树（如组织架构、商品分类）的主流做法，但 $graphLookup 极易配错方向、爆内存或查空。关键不是“怎么用”，而是“怎么防翻车”。
- 方向必须是
connectFromField: "parent_id"→connectToField: "_id"：表示“从当前节点的parent_id出发，去找其他文档的_id”，这才是向下查子孙；反着写就是在查祖先 - 不加
maxDepth就等于开盲盒：$graphLookup默认深度 100，但业务树通常 4–6 层封顶，设成maxDepth: 5是底线 - 必须加
restrictSearchWithMatch过滤无效节点，比如{ status: "active" }，否则已删除节点会参与遍历，内存占用指数增长 -
parent_id字段必须建索引：db.nodes.createIndex({ parent_id: 1 })，否则每次匹配都全表扫，10 万节点时聚合可能卡死 - 返回结果是扁平数组，不是树形结构：
as: "descendants"得到的是一个包含所有子孙的列表，要渲染成树还得在应用层按parent_id分组+递归组装
path 字段前缀匹配为什么比 $graphLookup 更稳？
当你要支撑高频菜单展开、面包屑、权限校验这类需求，path 是经过生产验证的“土办法”，它把树的拓扑关系转成字符串前缀，用索引就能秒出结果。
- 存法示例：
{ _id: "roles", path: "/system/users/roles/", level: 3 }，注意首尾带/，避免/sys匹配到/system - 查二级菜单：
db.menus.find({ path: { $regex: "^/system/[^/]+/$" } })，配合createIndex({ path: 1 })走索引 - 移动节点时，必须批量更新后代：
db.menus.updateMany({ path: { $regex: "^/system/users/" } }, { $set: { path: "/system/staff/" } })，别单条查再改 - 需要面包屑？额外加
ancestors: ["system", "users"]数组字段，查上级菜单就是find({ _id: { $in: doc.ancestors } })，再建个createIndex({ ancestors: 1 }) - 别指望靠
$graphLookup实时算路径——它慢、不可控、容易被干掉；path和ancestors必须在插入/移动时由后端同步写入，这是责任边界
真正容易被忽略的点是：树形结构从来不是纯数据库问题。环路检测（A 移到自己子孙下）、状态一致性（软删除节点是否参与查询）、租户隔离（tenant_id 必须进所有索引）这些，都得在应用层兜底。MongoDB 只管存和查，不管逻辑正确性。
