应使用引用id（parent_id）加ancestors路径字段方案，而非嵌套文档；部门与人员均存祖先路径数组并建多键索引，确保查询高效、更新原子、迁移可控。
部门树用嵌套文档还是引用 ID？
嵌套文档（children 数组）看着省事，但实际一改就卡：重命名父部门、移动子部门、跨树合并，全得递归更新整条链。MongoDB 不支持原子性跨文档更新，$push 或 $set 深层字段容易漏掉层级，查 find({ "children.1.children.0.name": "研发部" }) 这种查询还不可靠——数组索引不固定，一删节点就错位。
更稳的方案是每个部门存 parent_id（字符串类型，对应上级 _id），再加一个 ancestors 字段存祖先 ID 路径，比如 ["org_abc", "dept_101"]。这样查“所有研发部下属部门”只要 find({ ancestors: { $in: ["dept_101"] } })，走索引快；移动部门只需改一条记录的 parent_id 和 ancestors，不用动其他文档。
-
ancestors必须在应用层维护，插入/移动时手动计算，别依赖聚合管道实时生成 - 避免用数字型
_id，防止和旧系统 ID 冲突；统一用ObjectId()或语义化字符串如"dept_hr_2024" - 给
ancestors建多键索引：db.departments.createIndex({ ancestors: 1 })
人员如何关联到部门树？别只存 dept_id
只存一个 dept_id 字段，查“张三所在部门的所有上级部门”就得反复 lookup，性能差还容易超内存。真正要的是“路径可追溯”，所以人员文档里直接存 dept_path，比如 ["org_abc", "dept_101", "team_fe"]，和部门的 ancestors 对齐。
这个字段必须和部门变更同步更新。人员调岗不是简单改 dept_id，而是触发一次路径重算：先查新部门的 ancestors + 自身 _id，拼成新 dept_path，再 $set 进人员文档。否则会出现人还在 A 部门，dept_path 却指向 B 部门祖先的脏数据。
- 人员集合加索引：
db.users.createIndex({ dept_path: 1 })，支撑按部门树任意层级查人 - 不要在人员文档里冗余存部门名等字段——名称变，所有相关人要批量更新，风险高
- 如果允许一人多部门（如兼任），
dept_path改成数组，每个元素是完整路径，但查询逻辑变复杂，慎用
查“某部门下所有人”为什么慢？索引和投影关键在这儿
常见写法 db.users.find({ dept_path: { $elemMatch: { $eq: "dept_101" } } }) 看似对，但如果没索引或投影太宽，会扫全表+加载大量字段。核心是两点：索引必须覆盖 dept_path，且查询时用 $in 比 $elemMatch 更高效（尤其当 dept_path 是字符串数组时）。
正确姿势是：先确保 dept_path 有索引，再用 find({ dept_path: "dept_101" }) ——MongoDB 多键索引天然支持数组成员匹配，不需要显式 $elemMatch。再配合 .project({ name: 1, email: 1, _id: 1 }) 只取必要字段，避免传输大文档。
- 别对
dept_path用$regex查前缀，它无法走索引；想查“所有一级部门的人”，应在部门文档里加level: 1字段，人员同步带过去 - 聚合管道里做
$lookup关联部门信息时，限制输出字段，否则内存暴涨 - 部门树深度超过 5 层后，
dept_path数组长度变长，写入略增开销，但远小于读时反复 join 的代价
迁移老系统数据时最常崩在哪？
老系统部门 ID 是自增整数，新 MongoDB 用 ObjectId，直接导入会导致 parent_id 和 _id 类型不一致，$lookup 全失效。更隐蔽的是部门名称重复：老系统允许“北京分公司-研发部”和“上海分公司-研发部”，新设计若只按 name 去重，就丢数据。
迁移脚本必须做三件事：ID 统一转为字符串并保持可读性（如 "old_dept_123"）；用完整路径（full_path: "北京分公司/研发部/前端组"）去重并生成唯一 _id；最后一步才是算 ancestors 和人员 dept_path。
- 千万别边迁边服务——停写窗口期内，用
mongodump导出后再处理，避免增量同步逻辑错乱 - 验证环节重点跑：任意部门查子孙部门数 vs 查该部门路径下人数，两个数字必须严格相等
- 部门树修改操作（增删改移）务必走封装好的 service 方法，禁止在业务代码里直接
updateOne部门文档
ancestors / dept_path）的准确性，完全取决于每次变更时是否原子性更新所有相关字段——这里没捷径，也没中间状态可容忍。 
