物化路径（Materialized Paths）是MongoDB组织架构树最稳妥方案，需用ObjectId字符串拼接path、限制长度≤512、仅用点号分隔、建复合索引并冗余ancestors数组与level字段，变更操作须事务保障。
物化路径（Materialized Paths）是 MongoDB 中组织架构树最稳妥的选择，尤其适合读多、层级固定、需快速查子部门/上级链的场景。但直接拼字符串或用数字 ID 就存 path，90% 会出错。
path 字段必须用 ObjectId 字符串拼接，不能用数字
组织架构节点 ID 如果是数字（比如 1、10、104），按字典序匹配时 "1.10" 会排在 "1.2" 前面，导致 $regex: "^1.2" 漏掉 1.2.10 这类节点。MongoDB 不做数值解析，只做字符串前缀匹配。
正确做法是统一转成 24 位 ObjectId 字符串再拼接：
- 根节点：
_id: ObjectId("65a1b2c3d4e5f67890123456") - path 示例：
"65a1b2c3d4e5f67890123456.65a1b2c3d4e5f67890123457.65a1b2c3d4e5f67890123458" - 插入前校验：
path.length ≤ 512，防止超长导致索引失效或写入拒绝
分隔符只能用点号（.），且末尾不加
路径中若混用 $、:、/ 等 MongoDB 元字符，后续用 $regex 或字段投影（如 { path: 1 }）时必须反复转义，极易漏掉或写错。点号是唯一安全、无歧义、且被官方文档默认推荐的分隔符。
关键细节：
- 始终以根节点
_id开头，确保path: { $regex: "^65a1b2c3d4e5f67890123456\." }能精准命中所有后代（注意双反斜杠转义） - 末尾不加多余点号，比如不能是
"a.b.c."，否则^a.b.会误匹配a.b.c.d但漏掉a.b.c自身 - 业务层写入新节点时，必须用父节点当前
path+"."+ 当前节点_id拼接，禁止“先查父节点再拼”——并发写入下可能读到过期值
必须建前缀索引，且优先用复合索引
只对 path 建单字段索引 { path: 1 } 是基础，但生产环境远远不够。组织架构常带租户隔离、状态筛选等条件，单索引无法跳过扫描。
推荐组合：
- 高频查某部门下所有子部门：
db.orgs.createIndex({ tenant_id: 1, path: 1 }) - 查所有一级部门（即根直系）：
db.orgs.createIndex({ tenant_id: 1, level: 1, status: 1 })，配合冗余level字段（整数，根为 1） - 避免全文索引：
text索引会把path拆成多个 token，彻底破坏层级语义
面包屑和祖先判断要靠 ancestors 数组，不能只靠 path 字符串
path 字符串能高效查子树，但拿不到「从根到当前节点」的完整路径用于前端渲染，也无法快速判断 A 是否是 B 的祖先（比如权限校验）。这时候必须冗余一个 ancestors 数组。
示例文档：
{ "_id": "65a1b2c3d4e5f67890123458",
"name": "HRBP组",
"path": "65a1b2c3d4e5f67890123456.65a1b2c3d4e5f67890123457.65a1b2c3d4e5f67890123458",
"ancestors": ["65a1b2c3d4e5f67890123456", "65a1b2c3d4e5f67890123457"],
"level": 3,
"tenant_id": "t-123" }
操作要点：
-
ancestors存_id字符串，不是 name —— 重命名不影响一致性 - 插入/移动节点时，
ancestors和path必须原子更新；建议用updateMany+ 正则条件批量改后代，别单条循环 - 查面包屑：
db.orgs.find({ _id: { $in: doc.ancestors } }, { name: 1, _id: 1 })，加索引{ _id: 1 }即可走索引
真正容易被忽略的是：组织架构变更虽不如商品分类频繁，但一次移动部门可能影响数百个员工归属。path 和 ancestors 的更新必须放在事务里，且应用层要处理好失败回滚——不是所有驱动都默认开启事务，得显式调用 session.startTransaction()。
