部门移动必须原子更新parent_id和ancestors；查询人员应使用dept_path等值匹配并建多键索引；禁止在用户文档中冗余存储部门名称；path字符串字段为可选加速项，须与ancestors同步更新。
部门移动必须原子更新 parent_id 和 ancestors
部门移动不是改一个字段的事。只改 parent_id 而不重算 ancestors，会导致人员查“上级部门”时路径断裂——比如人还在研发部，dept_path 却指向已失效的旧祖先链。
正确做法是在应用层一次性完成三件事：
- 查出目标父部门的完整
ancestors数组（含自身_id） - 拼接新
ancestors：原数组去掉最后一项 + 新父部门的ancestors+ 当前部门_id - 用
updateOne({ _id: deptId }, { $set: { parent_id: newParentId, ancestors: [...newAncestors] } })原子提交
别依赖聚合管道实时生成 ancestors——写入延迟或并发写入时极易产生脏数据。
人员查询性能取决于 dept_path 索引与查询写法
查“某部门下所有人”，最常见错误是写成 find({ dept_path: { $elemMatch: { $eq: "dept_101" } } })。这不仅慢，还可能漏掉数据——因为 $elemMatch 要求匹配整个数组元素，而 dept_path 是字符串数组，直接用 $in 或等值匹配更准更快。
确保两点：
-
db.users.createIndex({ dept_path: 1 })已创建（多键索引，自动支持数组字段） - 查询统一用
find({ dept_path: "dept_101" })，而非$elemMatch或正则 - 投影精简：只取必要字段，如
{ name: 1, phone: 1, _id: 1 }，避免加载冗余字段拖慢响应
如果业务允许一人多部门，dept_path 改为二维数组（如 [["org_a", "hr"], ["org_a", "it"]]），但此时必须用 $elemMatch + $in 组合查询，且索引仍有效——只是查询逻辑变重，慎用。
避免在人员文档里存部门名称等可变字段
有人习惯在用户文档里加 dept_name、dept_level 字段，图查询方便。但部门重命名或结构调整时，就得批量更新所有相关人员，一次操作可能波及上万人，失败风险高、回滚困难。
真正该做的只有两件：
- 人员文档只存
dept_path（和部门ancestors对齐） - 前端/服务层按需查部门集合补全名称——查一次缓存，比写一万次安全得多
缓存可用 TTL 控制，部门名变更后最多延迟 5 分钟生效，远优于强一致性带来的写放大。
物化路径 path 字符串字段是兜底加速项
当组织树深度超过 6 层、或首页需快速展开“直属+二级下属”时，ancestors 数组查询仍可能不够快。这时加一个 path 字段（如 "org|hr|recruit"）并建普通索引，能绕过所有数组匹配开销。
使用要点：
-
path必须用|分隔，不能用.或/ - 查子树用
{ path: { $regex: "^org\|hr\|" } }，注意双反斜杠转义 - 必须有
{ path: 1 }索引，否则正则退化为 COLLSCAN -
path和ancestors必须同写同更新，二者不一致时以ancestors为准（它是结构化数据，path是衍生加速字段）
这个字段不参与业务逻辑判断，只服务高频只读场景。写入成本增加一点，换来首屏加载从 800ms 降到 40ms，值得。
