Laravel递归循环处理树形结构数据

你很可能被所谓的“无限递归”坑过，尤其是在用 Lara vel Eloquent 处理树形结构的时候。明明只是想把父子级数据一次性取出来，结果不是爆了内存，就是返回一堆重复的节点——这时候千万别怀疑 PHP 太弱，先想想递归的终止条件有没有被你顺手丢掉。

那为什么直接用 with('children') 会出问题？简单说，Eloquent 的 with() 压根就不是为无限嵌套设计的。你写个 with('children.children.children')，撑死了也就固定查三层；万一哪天树长深了，漏掉的节点就直接消失。如果非要写闭包递归调用自己，比方说在 scope 里不断重调 withChildren()，那 PHP 光建查询上下文就能让你内存撑爆，再遇上 xdebug.max_nesting_level 的限制，直接报错是常态。

常见报错信息无非是这几条：Fatal error: Allowed memory size exhausted、Maximum function nesting level reached，或是返回结果里同一个节点出现多次。原因也很明确——没缓存已处理过的 ID，也没过滤已经挂上树的节点。

踩坑清单倒是不难记：

• 模型的 accessor 或 scope 里隐式触发递归查询，比如在 getTreeAttribute 里又调 $this->children，等于给自己挖循环依赖
• 别指望 with() 能帮你自动推导关系深度，它不会做循环检测
• 如果你用了软删除，children() 关联默认不包含已软删节点，树会在断点处直接截断，必须显式加上 withTrashed() 才能维持完整性

说到 buildTree() 这种手动组装方案，虽然看起来逻辑清晰，但 80% 的空数组或 Array to string conversion 错误都不是递归本身的问题，而是底层数据没对齐。核心要点其实只有三个：

• id 和 parent_id 字段类型必须一致，都用 unsignedBigInteger，并且在 PHP 里用 (int) 强转后再比较，避免字符串 "1" 对不上整数 1
• parent_id 必须允许为 null（根节点），千万别设成 NOT NULL DEFAULT 0，否则插入根节点时直接违反约束
• 别忘了先用 groupBy('parent_id') 把扁平集合分组，而不是每次 filter() 遍历全量数据——后者是 O(n²) 的复杂度，几百条数据就开始卡顿了

关键代码段大致是这样的：

public function buildTree($groups, $parentId = null){    $items = $groups->get($parentId, collect());    return $items->map(function ($item) use ($groups) {        return $item->merge(['children' => $this->buildTree($groups, $item->id)]);    });}

不过话说回来，buildTree() 也不是银弹。什么时候该换方案？当业务从“读多写少”变成“频繁动树结构”的时候，它就彻底成了瓶颈。比方说移动一个节点，邻接表方案要更新该节点所有后代的 parent_id，N 层就得 N 次 UPDATE；换成 spatie/lara vel-nested-set，它只需改 lft 和 rgt 两个数字，性能就完全不是一个量级了。

这个包还额外自带 isDescendantOf()、getSiblings() 这些实用方法，省得你自己拼 whereRaw('path LIKE ?')。迁移成本也很明确：运行 php artisan vendor:publish --provider="SpatieNestedSetNestedSetServiceProvider" --tag=migrations，再跑一趟 php artisan migrate 就行。

至于 lara vel-adjacency-list 这个包，它的本质是帮你生成 MySQL 8.0+ 或 PostgreSQL 的 WITH RECURSIVE SQL，不是纯 PHP 方案。它确实能一次查出带 depth、path、is_cycle 的完整子树，但先确认数据库版本撑得住再说。

• MySQL 必须 ≥ 8.0，5.7 不支持 WITH RECURSIVE，硬跑会报 SQLSTATE[42000]: Syntax error
• 开启 cycle detection 后，查询会自动加 CYCLE 子句并返回 is_cycle 字段，但前提是模型里定义了 getPathKeyName()，否则路径解析就翻车
• 这个包不替代数据校验——DB 层仍可能存入循环数据（比如 A→B→C→A），CTE 只是在查询时发现并中断，并不阻止写入

最容易忽略的一点是：CTE 查询结果返回的是扁平集合，不是嵌套对象。你得自己根据 depth 或 path 重新组织一次，或者干脆让前端直接消费扁平结构配合 CSS 缩进来展示，省下后端递归组装的麻烦。