path字段用ObjectId字符串拼接+前缀索引是最稳妥的多级分类建模方式，因字典序等价层级序、避免正则歧义、支持高效子树查询且写入仅更新单文档。
path 字段用 ObjectId 字符串拼接 + 前缀索引，是当前（2026年）最稳妥的多级分类建模方式。别一上来就选 ancestors 数组或嵌套集，它们在真实业务中容易卡在写入一致性或查询歧义上。
为什么 path 比 parent_id 更适合电商/内容类分类树
父引用模式（每个文档存 parent_id）看着简单，但查“所有三级类目下的商品”就得递归聚合，层级一深就超时；移动节点还要批量更新后代 parent_id，事务没包住就数据错乱。path 把完整路径存成字符串，一次 $regex 就能命中整棵子树，且写入只改单条文档。
常见错误现象：
- 用数字 ID 拼
path（如"1.10.23"），结果$regex: "^1.1"同时匹配到"1.1"和"1.10" - 路径里混用
.和,分隔符，导致$regex转义混乱 - 没给
path字段建升序索引，^xxx查询走全表扫描
path 字段必须怎么存才不出错
核心是保证字典序等价于层级序，且不触发 MongoDB 特殊字符解析：
- 一律用
ObjectId字符串（24位十六进制），例如"65a1b2c3d4e5f67890123456.65a1b2c3d4e5f67890123457"，禁用数字或自增 ID - 分隔符只用英文点号
.，不用,、/或$——后者在$regex或投影中需双重转义 - 路径以根节点
_id开头，末尾不加.，例如根为"65a1b2c3d4e5f67890123456"，其子节点为"65a1b2c3d4e5f67890123456.65a1b2c3d4e5f67890123457" - 应用层写入前校验
path长度 ≤ 512 字符，避免撑爆索引项（B-tree 单节点限制）
查子树、查同级、查父链各用什么操作
同一 path 字段，不同目标对应不同查询写法，不是套一个正则走天下：
- 查某节点所有后代（子树）：
db.categories.find({ path: { $regex: "^65a1b2c3d4e5f67890123456\." } })—— 注意双反斜杠转义点号 - 查直接同级节点（同一父节点下的兄弟）：
db.categories.find({ path: { $regex: "^65a1b2c3d4e5f67890123456\.[^\.]+$" } })，配合$substrCP提取末段再去重 - 查父链（向上追溯）：靠应用层拆解
path字符串，用.split('.')得到祖先 ID 数组，再$in批量查——数据库层不做递归
别试图用 $regex 查中间段路径（如“所有含 Databases 的路径”），这种查询无法走索引，集合一大就慢。
索引和性能容易被忽略的细节
path 字段索引不是建了就完事：
- 必须建升序索引：
db.categories.createIndex({ path: 1 })，这是前缀匹配生效的前提 - 如果常按“层级深度”筛选（如只查一级类目），冗余一个
level字段并单独索引，比从path里数点号更可靠 - 避免对
path建全文索引（text），它会把"a.b.c"拆成"a"、"b"、"c"三个词，彻底破坏层级语义 - 若分类名含多语言，显式指定 collation：
db.categories.createIndex({ path: 1 }, { collation: { locale: "simple" } })，防止排序异常
真正麻烦的从来不是怎么读，而是怎么让写入不崩——每次新增节点，你得确保生成的 path 值全局唯一、顺序正确、长度合规。这个逻辑一旦散落在多个服务里，很快就会出现脏数据。
