递归终止条件逻辑颠倒会导致无限调用，表现为脚本卡住、超时或内存耗尽；根本原因是终止条件永远不成立，如该用 $n == 0 却写成 $n == 2，或该用 empty($data) 却误用 !empty($data)。
递归终止条件逻辑颠倒导致无限调用
最直接的表现是脚本卡住、超时或报 Allowed memory size exhausted / Maximum function nesting level of 256 reached。这不是性能问题，而是终止条件永远不成立——比如该写 $n 却写了 <code>$n >= 0，或该用 empty($data) 却用了 !empty($data)。
- 检查所有
if分支：终止条件必须在函数开头立即判断，且分支内必须含return，不能只写echo或赋值后继续往下执行 - 把终止条件单独抽出来测试：例如
var_dump($n 看它在首次调用、中间层、预期最后一层是否如你所想地变为 <code>true - 别依赖“看起来应该结束”：比如遍历数组时写
if ($i == count($arr))，但若数组为空，count($arr)是 0，$i初始为 0，条件立刻成立；可若初始$i = 1，就永远不成立
用深度计数器一眼定位失控点
加一个 $depth 参数，不是为了“防爆栈”，而是让它成为你的探针——一旦输出里出现连续多个相同深度的调用，说明参数没变、条件失效、正在原地打转。
- 函数定义加参数：
function walk($node, $depth = 0)，开头加if ($depth > 10) { error_log("DEEP: $depth, node=" . json_encode($node)); return []; } - 每次递归调用时传
$depth + 1，别漏掉——常见错误是写了walk($next, $depth)忘了+1 - 日志里如果看到
DEEP: 5、DEEP: 5、DEEP: 5反复出现，说明这一层的输入参数根本没变，终止条件必然写反或漏判
阶乘/斐波那契类函数的典型翻车现场
这类数学递归最容易暴露条件错误，因为输入可控、预期明确。拿 factorial(3) 手动展开两遍，比看代码更快发现问题。
- 正确路径应是：
factorial(3) → 3 * factorial(2) → 3 * 2 * factorial(1) → 3 * 2 * 1 - 如果实际跑出
factorial(3) → 3 * factorial(2) → 3 * 2 * factorial(1) → 3 * 2 * 1 * factorial(0) → ...，说明终止条件漏了$n == 0，或写成了$n == 2 - 斐波那契中写成
if ($n == 1) return 1;但没处理$n == 0，调用fib(0)就直接掉进递归深渊
数组递归遍历时 key 或 count 判断失准
用 count($arr) === 0 做终止条件看似合理，但遇上 null、false、字符串或对象，count() 返回 0 或警告，条件反而绕过，后续操作崩塌。
- 先做类型断言：
if (!is_array($arr) || empty($arr)) { return []; }，empty()对null/[]/false都安全 - 别在递归体里改原始数组（如
array_shift()），这会破坏外层对长度的预期；要用索引或键迭代，让参数显式收敛 - 调试时打印
gettype($arr)和count($arr)，确认每层传入确实是数组且长度递减
真正难发现的，是终止条件“看起来成立”，但只在特定输入下失效——比如处理数据库结果时，if (!$children) 对空数组返回 true，但对 null 返回 false，而查库失败偏偏返回 null。这种时候，光看逻辑没用，得看真实数据流。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
