最直接的无限级分类方案是用 parent 字段存父ID，需建索引、防循环引用，并配合 ancestors 数组优化祖先查询；查子孙用 $graphLookup 但需限深度和过滤。
用 parent 字段存父ID是最直接的无限级分类方案
MongoDB 本身不支持递归查询，所以“无限级”必须靠应用层或聚合管道手动展开。最常用、最易理解的方式就是每个文档加一个 parent 字段，指向其直接父节点的 _id（或自定义 ID）。它不依赖嵌套结构，增删改查都符合直觉，适合大多数 CMS、商品类目、组织架构等场景。
注意：这个模式下，查某节点的所有祖先或所有子孙，都需要多次查询或一次复杂聚合——不是点一下就出来的，得自己写逻辑。
-
parent值为null或ObjectId("000000000000000000000000")表示根节点，别用字符串"null"或空字符串，否则类型不一致会查不到 - 务必在
parent字段上建索引：db.categories.createIndex({ parent: 1 })，否则查子节点时性能断崖式下跌 - 避免用字符串 ID 模拟 ObjectId；如果业务用字符串 ID（如
"cat-123"），parent也必须是同类型，且索引要匹配
查所有子孙节点只能靠 $graphLookup，但有深度和内存限制
想从一个分类出发，一次性拿到它下面全部 5 级、10 级子类？MongoDB 提供了 $graphLookup，但它不是万能的：默认最多展开 100 层（可调但不建议超 20），且整个中间结果必须放进内存（RAM），数据量大时容易触发 errmsg: "Exceeded memory limit for $graphLookup..."。
典型错误是没设 maxDepth 或 restrictSearchWithMatch，导致查着查着就 OOM。
- 必须显式指定
maxDepth: 5（按业务真实最大深度设，别留余量） - 用
restrictSearchWithMatch: { status: "active" }过滤无效节点，减少中间数据量 -
connectFromField: "parent"和connectToField: "_id"方向别反——这是最容易配错的地方，反了就查不出任何结果 - 返回字段里别直接用
as: "children"，因为结果是扁平数组，不是树形结构；后续还得靠代码做分组
移动节点时只改 parent 字段，但得防循环引用
后台拖拽调整分类顺序，本质就是更新某个文档的 parent 值。看似简单，但一不小心就会让 A → B → C → A 这种环出现，后续所有递归逻辑（包括 $graphLookup）都会卡死或报错 "Cycle detected in graph"。
MongoDB 不提供内置环检测，这事必须由应用层兜底。
- 更新前先用聚合查一遍“目标父节点是否是当前节点的任意后代”，即跑一次反向
$graphLookup（connectFromField: "_id",connectToField: "parent"），看结果里有没有当前节点自身 - 不要依赖前端传来的
parent值直接入库，后端必须校验合法性 - 对高频移动场景，可以加一个
path字段（如"1/5/23"）辅助校验，但维护成本高，一般中小项目没必要
需要快速查祖先链？加个 ancestors 数组更稳
如果页面经常要显示“首页 > 电子产品 > 手机 > 苹果 > iPhone 15”，也就是频繁查某节点到根的完整路径，每次用 $graphLookup 反向查效率低、还容易超内存。这时候可以在插入/更新时，同步维护一个 ancestors 字段，存所有上级 _id 的数组（含根不含自己）。
代价是写操作变重一点，但换来读的确定性——查路径就是一次 find()，无聚合、无延迟、无失败风险。
- 插入新节点时，先查父节点的
ancestors，再拼上父的_id，赋给新节点的ancestors - 移动节点时，必须同时更新该节点及其所有后代的
ancestors——这是最麻烦的地方，建议用事务包裹（4.0+） - 数组长度就是层级深度，可用于快速筛选“只显示三级以内分类”，比聚合计算快得多
parent 引用够轻量，但一旦涉及路径展示或频繁祖先查询，就得补 ancestors 数组。没人能绕开“写时多算一点，读时少操心”的权衡。 
