物化路径字段应避免使用.和/，推荐用|或_分隔，如"org|hr|recruit"；需统一小写、去首尾空格及末尾分隔符，并配合ancestors数组字段与复合索引提升查询效率。
物化路径字段怎么存才不被MongoDB误解析
MongoDB 把 . 当作嵌套字段分隔符，所以存 path: "a.b.c" 会导致查询时被当成访问 a.b.c 字段，而不是字符串值。这不是 bug，是语法机制本身决定的。
必须避开 . 和 /：前者引发字段歧义，后者在 URL、某些驱动或反向代理中易被转义（比如 /api/v1/path?path=a/b/c 中的 / 可能被截断）。
推荐用 | 或 _，例如：path: "org|hr|recruit"。插入前还要做三件事：
- 强制
trim()去首尾空格 - 去重末尾分隔符（
"org|hr|"和"org|hr"是两个不同值，查不到同一子树） - 统一小写，避免
"HR"和"hr"被当成不同路径
为什么 $regex: "^org|hr|" 还是慢得像全表扫描
因为没建对索引，或者正则写法没对上索引前缀匹配规则。MongoDB 只有在 $regex 是“锚定开头 + 字面量前缀”时，才能走 { path: 1 } 索引。
必须同时满足三个条件：
- 索引是单字段
{ path: 1 }（别加text或复合字段） - 查询用
^开头，且后面是连续字面量（不能带.*、$、?等通配） - 注意反斜杠转义：JavaScript 字符串里写
"^org\|hr\|"，否则|不会被当字面竖线处理
错误示例：{ path: { $regex: "org.*hr" } } 或 { path: { $regex: "^org\|hr", $options: "i" } } —— 后者大小写不敏感会强制全索引扫描。
查“我的所有上级”为什么不能只靠 path 字段
path 是扁平字符串，反向提取祖先需要应用层切分和多次查询，既慢又容易出错（比如漏掉中间某级、空格没 trim 导致匹配失败）。
正确做法是同步维护一个 ancestors 数组字段，例如：{ _id: "recruit", path: "org|hr|recruit", ancestors: ["org", "hr"] }。
- 数组必须严格按从根到直接父的顺序存，不能跳级、不能颠倒
- 查上级就变成简单
find({ _id: { $in: doc.ancestors } })，一次命中 - 索引别只建
{ ancestors: 1 }，要建复合索引{ ancestors: 1, _id: 1 }，否则高基数数组会导致内存暴涨
路径深度超 8 层后性能断崖式下跌的原因
不是 MongoDB 本身限制，而是索引效率和文档体积双重衰减：
- 字符串越长，B-tree 索引节点分裂越频繁，查找路径变长；超过 20 层后，
path字段本身可能逼近 1KB，索引条目膨胀明显 - 单文档内若还存其他字段（如 name、desc、icon base64），16MB 上限很快吃紧
- 业务上极少真需要查第 12 级汇报线——如果出现，大概率是模型设计偏移，该拆分组织单元或加租户隔离
真正难处理的从来不是“怎么查更深”，而是“怎么让写入时路径计算不出错、移动时不漏更新、并发时不覆盖”。这些环节一旦松动，path 就从加速器变成数据污染源。
