生产环境优先选django-treebeard，因其支持数据库级锁、事务安全移动、自动索引与约束，而django-mptt轻量但易因异常导致lft/rght损坏、修复成本高。
用 django-mptt 还是 django-treebeard？选错库会卡死迁移
直接结论：生产环境优先选 django-treebeard，尤其涉及高并发写入或需支持数据库级锁的场景；django-mptt 更轻量但默认不支持事务安全的节点移动，且 MySQL 下 lft/rght 字段易因异常中断而损坏。
两者都基于“嵌套集模型（Nested Sets）”，但 treebeard 默认用 MP_Node 实现，底层通过字符串路径（如 '0001/0002/0003/'）规避整数字段竞争问题，迁移时自动建索引、加约束，而 mptt 依赖手动调用 rebuild() 修复断裂树——线上出错后恢复成本极高。
-
treebeard的get_children()和get_descendants()返回QuerySet，可链式过滤；mptt同名方法返回列表，需额外转.filter() - 若已有大量数据且不能停服，
treebeard支持load_bulk()批量导入，mptt的insert_node()是单条事务 - PostgreSQL 用户注意：
mptt的get_ancestors(ascending=True)在 PG 上可能顺序错乱，treebeard无此问题
MP_Node 模型定义里必须避开的三个字段名
treebeard 要求模型继承 MP_Node 并严格保留四个系统字段：path、depth、numchild、id。一旦重命名或覆盖，save() 会静默失败，后台日志只报 IntegrityError: null value in column "path" violates not-null constraint。
常见踩坑点：
立即学习“Python免费学习笔记（深入）”；
- 自定义主键名（如
uuid = models.UUIDField(primary_key=True)）→ 必须同时显式声明id = models.AutoField(primary_key=True)，否则path生成逻辑崩坏 - 字段名含
parent（如parent_category）→treebeard会误识别为父节点外键，导致add_child()插入位置错乱 - 在
Meta中设置ordering = ['name']→ 树遍历顺序被强制打乱，get_siblings()返回结果不可靠
正确写法示例：
from treebeard.mp_tree import MP_Node <p>class Category(MP_Node): name = models.CharField(max_length=100)</p><h1>不要定义 parent、path、depth、numchild 字段</h1><pre class='brush:python;toolbar:false;'># 不要覆盖 id 字段 node_order_by = ['name'] # 用 node_order_by 替代 ordering
移动节点时为什么 move_to() 比 add_sibling() 更安全？
用户拖拽菜单、调整分类顺序时，本质是变更节点在树中的相对位置。直接调 node.add_sibling('left', target=sibling) 看似直观，但若 sibling 正被其他请求修改，会触发 IntegrityError 或路径重复——因为 add_sibling 底层执行多条 UPDATE，缺乏原子性。
move_to() 则不同：它把整个子树（含所有后代）当做一个单元重新计算 path，全程在单个数据库事务中完成，即使并发操作也只会排队执行。
- 移动前务必先
node.refresh_from_db()，避免基于过期path计算新位置 - 目标节点（
target）必须是同级节点或自身祖先，传入后代节点会抛InvalidMoveToDescendant - 若需跨树移动（如从 A 分类移到 B 分类下），必须用
node.move_to(target, 'last-child')，不能用add_child()
查询深层后代时 get_descendants(include_self=False) 的性能陷阱
当树深度超过 5 层、总节点超 10 万时，get_descendants() 默认走全表扫描，即使 path 字段有索引，PostgreSQL 也可能放弃使用（因 LIKE '0001/0002/%' 前缀匹配在统计信息不足时被判定为低效）。
优化手段有限但关键：
- 确保数据库已对
path字段建立 B-Tree 索引（treebeard迁移时自动创建，但手动删过索引需补回） - 避免在
get_descendants()后接.select_related()——path查询本身不触发 JOIN，强行关联反而让查询计划变复杂 - 真要查 10 万+ 后代，改用原生 SQL：
SELECT * FROM myapp_category WHERE path LIKE %s，参数用node.path + '%'，绕过 ORM 层解析开销
最常被忽略的一点：树形结构天然不适合“分页查全部后代”。如果业务需要展示无限滚动的子分类列表，应该按层级预加载（查第 1 层 → 查第 2 层 → …），而不是一次 get_descendants().all()。
