Eloquent 的 parent_id 关系出错因 Laravel 无原生树形支持，belongsTo/hasMany 仅单层，递归预加载易致无限嵌套、N+1 或层级混乱；需显式定义关系、排序、避免懒加载，并在深查询或频繁获取后代时考虑 Closure Table 等替代方案。
为什么直接用 Eloquent 的 parent_id 关系会出错？
因为 Laravel 默认不提供树形遍历能力，belongsTo('parent') 和 hasMany('children') 只能查单层，一调 children()->with('children') 就无限嵌套或 N+1。更麻烦的是，where('parent_id', $id) 查子节点时，根本不知道当前节点在第几层，也无法按层级排序。
常见错误现象：Maximum function nesting level of '256' reached（递归没出口）、Undefined property: Illuminate\Database\Eloquent\Collection::$children（误把集合当模型用）、查询结果顺序乱（数据库默认不保序）。
- 必须显式定义
parent()和children()关系，并加orderBy('sort', 'asc')或orderBy('id') - 避免在 Blade 中写
@foreach($node->children as $child) {{ $child->children }}—— 这会触发懒加载，且无深度控制 - 不要依赖模型的
$appends或访问器动态计算层级，它不参与查询，也不能用于 WHERE 条件
怎么安全地获取某节点的所有后代（含子孙）？
邻接表没有内置“获取全部后代”方法，得手写递归查询。但直接 PHP 递归查数据库极容易 N+1，尤其树深 >5 时响应明显变慢。
推荐做法：用一次查询取出整棵树（或子树），再用 PHP 构建层级结构。前提是数据量不大（比如后台菜单、分类 ≤ 200 条）。
立即学习“PHP免费学习笔记（深入）”；
- 用
with(['children' => function ($q) { $q->orderBy('sort'); }])预加载一级子节点，再手动递归收集 —— 注意要传引用或返回数组，别在闭包里改模型属性 - 如果必须查任意节点的完整后代，先用原生 SQL 查出所有相关 ID：
SELECT id FROM categories WHERE id = ? OR parent_id = ? OR parent_id IN (SELECT id FROM categories WHERE parent_id = ?)—— 但这最多只支持 3 层，不通用 - 更稳的方式是加一个
scopeDescendantsOf()查询作用域，配合whereRaw('path LIKE ?', [$this->path . '%'])（需提前维护 path 字段）—— 这已超出纯邻接表范畴，但值得提一句：邻接表真不适合深查询
saveAsChildOf() 和 appendToParent() 怎么写才不破坏树结构？
Eloquent 没有内置方法，得自己封装。关键点不是“存”，而是“校验”和“清缓存”：不能让 parent_id 指向自己、不能形成环（A→B→C→A）、移动后要重置子树的 parent_id（仅限单层移动）。
- 移动前用递归查一遍目标节点是否是自己的祖先，函数名建议叫
isAncestorOf($candidate)，返回布尔值，别用模型方法直接查库 - 保存时用事务：
DB::transaction(function () use ($node, $newParent) { ... });，否则移动中途失败会导致树断裂 - 移动后清掉所有涉及节点的 Eloquent 缓存（如果有用
remember()），并注意：$node->refresh()不会刷新关联关系，得重新load('parent', 'children') - 别在
saved事件里自动更新updated_at或路径字段 —— 邻接表本身不含路径，强行加反而让逻辑变重
什么时候该放弃邻接表，换 Closure Table 或 Nested Set？
当你遇到这些信号，说明邻接表正在拖慢开发和运行：getDescendants() 调用频繁、树深经常 ≥ 4、需要按层级批量更新（如拖拽排序后同步整棵子树）、API 响应中要返回带 depth 字段的完整树 JSON。
邻接表唯一优势是增删节点快、结构直观；劣势是读多写少场景下，查询成本指数增长。Laravel 社区里 kalnoy/nestedset 插件虽好，但它要求你改表结构（lft/rgt 字段）、重写迁移、且不兼容软删除的默认行为。
最常被忽略的一点：邻接表 + 前端无限滚动树组件（如 Ant Design Tree）时，后端若每次只查一层，前端会发 10+ 请求 —— 这时候不如一次性查出全量树，用 JS 做客户端展开/折叠，反而更快更稳。
