Materialized Paths是MongoDB 7.0中多级分类最实用方案，需统一用ObjectId字符串拼接路径、禁用元字符分隔符、建前缀匹配索引，并配合level字段或hasChildren标识优化查询。
路径枚举（Materialized Paths）在 MongoDB 7.0 中仍是设计多级分类最实用、查询最直接的方案，但必须注意 _id 类型一致性、路径分隔符安全性和索引策略 —— 否则深度查询会慢，甚至匹配出错。
为什么不用嵌套集或祖先数组？
嵌套集（Nested Sets）写入成本高，每次插入/移动节点都要重算左右值，不适合频繁变更的分类树；祖先数组（Ancestors Array）虽支持 $in 快速查子树，但数组长度随层级增长，更新时易触发文档迁移，且无法天然表达顺序。而 Materialized Paths 用字符串存完整路径（如 "1.5.23.104"），读写平衡，配合正则或前缀索引即可高效支持“查某分类下所有子类”“查所有叶子节点”等常见场景。
path 字段怎么存才不踩坑？
关键不是“怎么拼”，而是“怎么保证可比较、可索引、无歧义”：
- 统一用
ObjectId字符串（而非数字）拼接路径，避免"1.10"和"1.2"的字典序错乱 —— 正确示例："65a1b2c3d4e5f67890123456.65a1b2c3d4e5f67890123457.65a1b2c3d4e5f67890123458" - 路径分隔符禁用点号（
.）以外的 MongoDB 元字符（如$、:），否则在$regex或字段投影中需反复转义 - 始终以根节点
_id开头，且末尾不加多余分隔符，确保path: /^65a1b2c3d4e5f67890123456./能精准命中其所有后代 - 业务层写入前校验路径长度（建议 ≤ 512 字符），防止超长路径导致索引失效或写入失败
MongoDB 7.0 怎么建索引才能让路径查询快？
别只建普通索引 —— Materialized Paths 的查询模式决定了索引必须适配前缀匹配：
- 对
path建升序索引：db.categories.createIndex({ path: 1 })，这是基础，支持$regex前缀匹配（如^65a...） - 若常按“最后一级分类 ID”筛选（如“所有一级类目”），可额外建
path的倒序索引 +$substrCP聚合提取末段，但更推荐冗余一个level字段并单独索引 - 避免在
path上建全文索引（text），它会把路径拆词，破坏层级语义 - MongoDB 7.0 支持
collation索引，若分类名含多语言，建议显式指定locale: "simple"避免排序异常
查子树、查父链、查同级，各用什么操作？
Materialized Paths 的灵活性体现在不同查询目标对应不同写法，不是一套模板打天下：
- 查某节点所有后代（子树）：
db.categories.find({ path: { $regex: "^65a1b2c3d4e5f67890123456\." } })—— 注意双反斜杠转义点号 - 查某节点完整父链（含自己）：先用应用层解析路径字符串得到所有祖先
_id，再find({ _id: { $in: [oid1, oid2, oid3] } })；MongoDB 7.0 不支持服务端直接切分字符串反查，别硬写聚合 - 查同级节点（同一父节点下的兄弟）：先查当前节点的
path，截掉最后一段得到父路径，再用$regex查该父路径下的所有直接子节点（即匹配"^parent_path\.[0-9a-f]{24}$"） - 查所有叶子分类（无子节点）：需额外维护
hasChildren: false字段，靠应用层更新保障；仅靠path无法区分“是叶子”还是“还没加子节点”
真正难的不是建模，而是路径变更时如何原子更新整条链 —— MongoDB 7.0 的单文档事务能保 path 和 parent 字段一致，但跨文档重命名仍需两阶段提交或应用层补偿。这点容易被忽略，直到上线后发现分类移动后子树丢失。
