物化路径法需路径格式（避用.和/，推荐|或_）、{path:1}索引及^字面量正则三者严丝合缝，否则$regex退化为全表扫描；路径须trim、去重分隔符、统一小写，深度超20层易致性能下降。
物化路径法在 MongoDB 中能实现子树查询毫秒级响应，但前提是路径格式、索引和查询写法三者严丝合缝——任一环节出错，$regex 就会退化为全表扫描。
path 字段怎么存才不触发字段嵌套解析
MongoDB 把 . 当作嵌套字段分隔符，所以用 path: "a.b.c" 会导致查询时被误解析成访问 a.b 字段下的 c 值。这不是 bug，是语法机制。
- 必须避开
.和/：前者引发路径歧义，后者在 URL 或某些驱动里易被转义 - 推荐用
|或_，例如path: "root|node_1|node_3" - 插入前强制 trim 并去重末尾分隔符：
"root|node_1|"和"root|node_1"是两个不同值，查不到同一棵子树 - 统一小写 + 去空格，避免
"Root"和"root"被当成不同路径
为什么建了 { path: 1 } 索引，$regex 还是慢
因为 MongoDB 只对左锚定（left-anchored）、字面量开头的正则才走索引——变量拼接、非 ^ 开头、中间匹配都会跳过索引。
- 必须用
^开头，且紧跟路径字面量：{ path: { $regex: "^root\|node_1\|" } } - 反斜杠要双写，否则 JS 字符串或 shell 会吃掉一层
- 绝不能写成
{ path: { $regex: ".*node_1.*" } }或{ path: /node_1/ }，这种必然全扫 - 索引本身没问题，但如果你查的是
/|node_3|/（中间匹配），即使有索引也只比无索引略快一点
查子树时怎么避免深度超限导致性能崩
path 字符串不是越长越好。WiredTiger 对单字段 >1024 字节的文档压缩率明显下降，写放大也会上升；深度超 20 层后，字符串长度很容易突破这个阈值。
- 路径中用短 ID 替代长名称：
_id: "u_8x2"比_id: "user_profile_settings"更安全 - 避免在 path 中存业务描述字段，只存可枚举、稳定、无空格的标识符
- 如果业务上真需要深于 30 层的树（如基因谱系、编译 AST），优先考虑祖先数组模式，而非硬撑物化路径
- 定期用
db.tree.aggregate([ { $addFields: { pathLen: { $strLenCP: "$path" } } }, { $sort: { pathLen: -1 } }, { $limit: 5 } ])监控最长 path
和 ancestors 数组方案比，什么情况下该换
物化路径不是万能解。当你发现频繁执行 updateMany 去批量修正 path（比如移动整棵子树），或者写入延迟开始抖动，就是信号。
- 祖先数组更适合「读多写少 + 需要灵活查任意祖先」的场景，比如权限系统中查“是否属于某部门及其所有上级”
-
ancestors字段建普通索引即可高效支持{ ancestors: "dept_a" }查询，无需正则 - 但 ancestors 数组无法原生支持“查从 root 到 node_X 的完整路径”，得靠应用层拼接或额外字段补足
- 真正卡点在于变更频率：如果每天有上千次节点移动，物化路径的字符串更新+索引重建成本会快速盖过查询收益
最常被忽略的是路径标准化逻辑——它不在 schema 里，也不在索引里，但一旦漏掉 trim 或大小写归一，后续所有查询都可能静默失效。把这个逻辑塞进 pre-save hook 或 ORM 的 save 拦截里，比事后 debug 强十倍。
