物化路径字段必须用|或_代替.和/，插入前需trim、去重末尾分隔符、统一小写；$regex查询需满足^+字面量前缀且索引为{path:1}；查上级须维护ancestors数组并建{ancestors:1,_id:1}复合索引。
物化路径字段必须避开 . 和 /
MongoDB 把 . 当作嵌套字段分隔符，存 path: "a.b.c" 会导致查询时被解析成访问 a.b.c 字段，而不是字符串值；/ 则在 URL、某些驱动或反向代理中易被截断或转义。这不是 bug，是语法机制本身决定的。
必须统一用 | 或 _，例如："org|hr|recruit"。插入前还要做三件事：
- 调用
trim()去首尾空格 - 删掉末尾冗余分隔符（
"org|hr|"和"org|hr"是两个不同值，查不到同一子树） - 统一转小写，避免
"HR"和"hr"被当成不同路径
$regex 查询为什么还是全表扫描
因为没满足索引前缀匹配的硬性条件。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 级汇报线——如果出现，大概率是模型设计偏移，该拆分组织单元或加租户隔离
真正容易被忽略的是：物化路径 + ancestors 数组这套组合，必须配套复合索引和严格的预处理逻辑，少一步，性能就回退到全表扫描级别。
