应采用 parent_id + ancestors 数组而非嵌套文档建部门树，因其支持高效查询、原子移动与索引加速；人员需冗余存储 dept_path 并建立多键索引；路径设计须规避分隔符陷阱、标准化格式并控制深度，同步更新必须事务保障。
直接用嵌套文档（children 数组）建部门树，上线两周后就会遇到移动部门卡顿、重命名失败、查询结果错位的问题——这不是配置问题，是模型选错了。
为什么 parent_id + ancestors 数组比嵌套文档更可控
嵌套文档看似直观，但 children 是数组，索引不固定：find({ "children.1.children.0.name": "研发部" }) 这种写法一删节点就失效；更新时还得递归遍历整条链，MongoDB 不支持跨文档原子更新，$set 深层字段极易漏层级。
parent_id + ancestors 把树结构“扁平化”：每个部门只存上级 _id 和完整祖先 ID 路径（如 ["org_abc", "dept_101"]）。这样：
- 查“所有下属部门”只需
find({ ancestors: { $in: ["dept_101"] } })，走{ ancestors: 1 }多键索引，毫秒响应 - 移动部门只改一条记录的
parent_id和ancestors，不用碰其他文档 -
ancestors必须在应用层计算并写入，不能靠聚合管道实时生成——否则写入延迟高、事务难保证
人员如何关联到部门树才不会拖慢查询
只存一个 dept_id 字段，查“张三所在部门的所有上级”就得反复 $lookup，内存溢出风险高，且无法利用索引加速。
正确做法是人员文档里直接存 dept_path（和部门的 ancestors 对齐），例如 ["org_abc", "dept_101", "team_fe"]：
- 调岗不是简单改
dept_id，而是先查新部门的ancestors，拼出新dept_path，再$set进人员文档 - 必须给
dept_path建多键索引：db.users.createIndex({ dept_path: 1 }) - 查“某部门下所有人”别用
$elemMatch，直接find({ dept_path: "dept_101" })更高效（前提是索引已建） - 禁止在人员文档里冗余存部门名——名称一变，全量更新成本极高
路径字段设计中三个容易被忽略的硬约束
ancestors 是数组，path 字符串（如物化路径）是另一条路，但无论选哪条，以下三点不满足，性能就会断崖下跌：
- 分隔符不能用
.或/：.会被 MongoDB 当作嵌套字段分隔符，/在 URL 或某些驱动里易被转义；推荐用|或_，如"root|dept_101|team_fe" - 路径值必须统一小写、trim 空格、去重末尾分隔符；
"root|dept_101|"和"root|dept_101"是两个不同值，查不到同一子树 - 深度超 20 层时，字符串长度易突破 WiredTiger 1024 字节压缩阈值，写放大上升；此时应切回
ancestors数组方案，而非硬撑物化路径
最常被跳过的环节是 ancestors 和 dept_path 的同步更新逻辑——它不在数据库 schema 里，却决定了整个树是否可信。写入路径变更的代码，必须和部门/人员更新操作跑在同一个事务里，否则几小时后就会出现人还在 A 部门、dept_path 却指向 B 部门祖先的脏数据。
