路径枚举适合读多写少、层级稳定、深度≤6、频繁查询祖先 - 后代关系的场景，如商品类目；不适用于高频移动节点、需兄弟排序或深度超 10 层的情况。
路径枚举模型在特定场景下值得使用，但不是通用解法。它适合读多写少、层级稳定、查询以“祖先 - 后代”关系为主且深度可控的树形结构。
什么情况下路径枚举真正好用
当你的业务中频繁需要判断“某个节点是否属于某目录下”“列出某分类的所有子项”“快速定位节点在树中的完整路径”，且树的深度通常不超过 5–6 层、节点移动不频繁时，路径枚举能用极简 SQL 实现高效查询。
- 比如：商品类目（家电 → 厨房电器 → 电饭煲）、文档系统（部门 / 项目 / 文档）这类人工维护、变更低频的静态分类
- 查询语句可直接用 LIKE ‘1/4/12/%’ 或 path LIKE ‘1/4/12%’ AND path != ‘1/4/12’，无需联表或递归
- 索引支持良好——对 path 字段建 B-tree 索引后，前缀匹配效率很高
它明显扛不住的几种情况
一旦写操作变多、层级动态加深或需要精确控制中间关系，路径枚举会迅速暴露短板。
- 移动节点需批量更新所有后代 path 字段（如把 /1/4/12/ 下全部迁到 /1/7/，要 UPDATE 所有匹配行），并发下易出错且影响性能
- 无法直接表达“兄弟顺序”“是否为直系子节点”等关系，额外字段（如 sort_order）仍需维护
- path 字段过长（如深度超 10 层 + 大 ID）会导致索引膨胀、比较变慢；MySQL 对 LIKE 前缀匹配虽快，但 NOT LIKE 或模糊中间段（如 %/4/%）就无法走索引
和嵌套集、闭包表比起来差在哪
嵌套集（Nested Set）写入成本更高但范围查询极快；闭包表（Closure Table）写入轻量、关系表达最灵活，只是多一张关联表。路径枚举是三者中“最省表结构、最依赖字符串操作”的折中方案。
- 如果你已有成熟 ORM，且团队熟悉字符串处理与正则，它上手最快
- 若系统未来要支持 拖拽排序、跨树迁移、实时协同编辑，建议从闭包表起步
- 不要为了“看起来简洁”而选路径枚举——ID 拼接的 path 字段在调试、日志、API 返回时反而增加解析负担
想用？至少做三件事
降低后期翻车概率，不是加个 path 字段就完事。
- 约定分隔符（推荐 ‘/’，避免 ‘.’ 或 ‘-‘ 引发歧义），统一末尾是否加 ‘/’（建议不加，减少冗余）
- 给 path 字段加 CHECK 约束（如 PostgreSQL 的 path ~ ‘^(d+/)*d+$’）或应用层校验，防止非法格式入库
- 写一个轻量级迁移 工具 函数，用于节点移动时安全重写子树 path，别靠手工 UPDATE
不复杂但容易忽略：路径枚举的价值不在“能实现”，而在“是否让常见查询变得更简单、更可靠”。先理清你 80% 的树查询长什么样，再决定要不要用它。
