祖先数组模型需严格按根到直接父顺序存 _id，空数组表示根节点；查子项须建 {ancestors: 1, _id: 1} 复合索引，移动目录须事务内 updateMany 批量重写祖先链，并单独维护 parent_id 字段。
祖先数组模型能显著加速「查某个目录下所有子目录/文件」和「判断某路径是否属于某目录树」，但对查父目录、兄弟目录无效；它不是开箱即用的银弹，必须配合严格的数据写入逻辑和复合索引才能生效。
ancestors 字段怎么存才不白建
数组必须按从根到直接父的顺序存储 _id，不能跳级、不能颠倒、不能混入名称或路径字符串。例如目录 "reports_q3" 属于 "finance" → "dept" → "root"，其 ancestors 必须是 ["root", "dept", "finance"]。
- 存 name 或 slug（如
"Finance"）会导致重命名后全量更新，且无法与_id级联校验权限 - 末尾加自己
_id是常见错误：祖先数组只管“往上是谁”，不包含当前节点——那是_id本身的事 - 空数组
[]表示根节点，不是null或缺失字段，否则$all查询会漏掉
查“所有子项”时为什么用了 ancestors 还慢
只建 { ancestors: 1 } 是典型浪费：MongoDB 对数组字段做单字段索引时，默认触发多键索引扫描，文档越多、层级越深，executionStats.nReturned 越低，实际走的是内存过滤而非高效定位。
- 必须建复合索引：
db.files.createIndex({ ancestors: 1, _id: 1 })—— 支持前缀匹配同时支持去重或排序 - 如果常按用户+目录查（如
tenant_id: "t_123", ancestors: "shared"），索引得写成{ tenant_id: 1, ancestors: 1, _id: 1 } - 别对
ancestors建唯一索引或 TTL 索引，MongoDB 明确不支持
移动目录时 updateMany 怎么写才不出错
移动操作本质是批量重写后代节点的 ancestors，靠应用层循环 find→updateOne 极易漏更新或并发冲突，必须原子化处理。
- 先用
find({ ancestors: { $all: ["old_parent_id"] } })定位整棵子树（注意：不是$in，那是查任意匹配） - 再用
updateMany批量重写：{ ancestors: { $set: [...newAncestors] } }，其中newAncestors= 原祖先链去掉old_parent_id，再拼上new_parent_id - 务必在事务中执行这组操作，否则中途失败会导致树结构断裂
- 软删场景下，可先置
status: "moved"，等批量更新完成再删原节点，避免查询期间出现“找不到父但又没归属”的中间态
为什么查“上级目录”还得额外查 parent 字段
ancestors 存的是祖宗链，不包含直接父节点——所以点击 "reports_q3" 后想显示它的父目录 "finance"，不能从 ancestors 里取最后一个值了事，因为数组顺序依赖插入逻辑，且可能被误改。
- 必须单独维护
parent_id字段，并确保它始终指向ancestors[ancestors.length - 1]（即最后一个祖先） - 前端面包屑渲染应优先用
ancestors+_id批量查节点名，而不是逐层递归查parent_id - 权限继承类逻辑（如“只有 finance 目录有读权限，则其所有子孙都可读”）才真正依赖
ancestors的存在性检查：{ ancestors: "finance" }
最容易被忽略的一点：祖先数组的写入成本是刚性的——每次新增、移动、重命名，都必然引发后代文档的批量更新。当目录树深度超 15 层、子节点数过万时，这个延迟会明显暴露，此时该考虑是否真需要动态树，还是把高频访问路径预计算为扁平化视图。
