必须硬编码递归深度限制，因PHP无运行时熔断机制，栈溢出发生在C层分配阶段直接崩溃；应在函数签名显式传入当前层级与阈值（如100～200），超限即返回null，禁用全局变量计数和throw异常，并采用引用传参避免copy-on-write开销。
递归深度必须硬编码限制，不能靠配置
PHP 没有运行时自动熔断机制，max_execution_time 和 memory_limit 都拦不住栈溢出——它发生在 C 层栈分配阶段，直接 segfault。你不能指望 xdebug.max_nesting_level 生产生效，它只影响 Xdebug 调试器。
正确做法是在函数签名里显式传入当前层级和最大阈值，比如：buildTree($parentId, &$tree, $level = 0, $maxLevel = 150)。每次递归前判断 if ($level >= $maxLevel)，立刻 return 或 error_log 并退出。
- 阈值设 100～200 是安全区间，超过基本说明数据异常或存在父子环
- 别用全局变量存层级计数，多线程/协程下会错乱
- 终止时返回
null或空数组，别 throw 异常，避免上层未捕获中断流程
引用传参是底线，别用 array_merge 拼接
常见错误是写成 return array_merge($current, buildTree($id))，每次递归都创建新数组、触发 copy-on-write、GC 压力飙升，内存峰值翻倍，还拖慢速度。
必须用引用传入结果容器：buildTree(0, $result) 入口调用，所有子级递归都操作同一个 $tree 数组引用。这样避免中间数组反复构造销毁，也规避了 PHP 的写时复制开销。
立即学习“PHP免费学习笔记（深入）”；
- 入口不能写成
$result = buildTree(0)，那是教科书式错误 -
foreach ($categoryMap[$parentId] ?? [] as $item)中的$categoryMap应该是预加载的扁平映射表，不是每次查库 - 如果树特别深但节点少，可考虑用
SplStack替代普通数组，语义更清晰
树遍历优先用迭代，别信“尾递归能省栈”
PHP 不支持尾调用优化，return buildTree($id, $tree, $level + 1) 这种写法照样增长调用栈。唯一彻底规避栈风险的方式，是改用 while 循环 + 数组模拟栈。
典型结构：$stack = [[ 'id' => 0, 'level' => 0 ]]，循环中 array_pop() 取节点，处理后把子节点 array_push() 进栈。整个过程零函数调用，栈空间恒定。
- 漏掉“把子节点压栈”这步，就会遍历不全
- 用
array_shift()+array_unshift()可实现 BFS，但性能略差于 DFS 的 pop/push - 注意变量作用域：原递归里的
$level、$path等，在迭代里要作为栈元素字段显式携带
数据库层能递归就别在 PHP 做
如果你用的是 MySQL 8.0+ 或 PostgreSQL，直接用 SQL 的 WITH RECURSIVE 查出完整树，PHP 只做一次扁平化组装。这样 PHP 侧零递归、零栈压力、一次 IO 解决问题。
适用前提是分类总数可控（比如
- 别在循环里嵌套
SELECT * FROM categories WHERE parent_id = ?，N+1 查询 + N 层递归 = 双重爆栈风险 - 预加载全部数据后构建
$map[$parentId][] = $row映射表，再用迭代展开，是平衡内存与安全的通用解法 - 如果树节点带权限或状态需运行时计算，才考虑 PHP 侧分层懒加载，但必须配深度限制 + 迭代
实际项目里最容易被忽略的，是递归逻辑藏在魔术方法或事件回调里——比如 __get() 里又触发了另一个对象的 getChildren()，表面看没递归，实则隐式成环。这种问题不会报“maximum nesting level”，而是静默卡死或 segfault，查起来极难。
