递归变慢主因是栈帧堆积、重复计算和内存失控三者并发。每次调用压栈帧，深递归致栈与内存暴涨；无缓存时如fibonacci会指数级重复计算；应优先迭代替代、用生成器或加缓存，并避免递归中array_merge、json_encode等高开销操作。
递归函数处理大数据变慢，核心原因不是“用了递归”，而是栈帧堆积、重复计算、内存失控这三件事同时发生。
为什么递归调用一多就卡住？
每次递归调用都会在 PHP 的调用栈里压入一个新栈帧，保存局部变量、参数和返回地址。树深 1000 层？栈帧就 1000 个；如果每层还拷贝数组或对象，内存增长是指数级的。更糟的是，没加缓存的递归（比如原始 fibonacci）会反复算同一子问题，fib(30) 调用次数超过百万次——CPU 全花在重复计算上，不是卡，是真在干无用功。
- 栈溢出前往往先内存爆掉：PHP 默认栈大小有限，但更常见的是
memory_limit先被耗尽 - OPcache 对递归本身无效：它只加速脚本解析，不减少运行时调用开销
- Xdebug 开着？递归性能直接打骨折：每个栈帧都要被监控，开销翻几倍
怎么把递归改成不卡的写法？
别硬扛，优先考虑「能不能不用递归」。大多数树形遍历、路径查找、扁平化场景，都有更稳的替代方案：
- 用
foreach+ 队列/栈模拟迭代：把待处理节点存进数组，array_shift()或array_pop()取出，显式控制深度，彻底避开栈限制 - 改用生成器（
yield）：如flattenGenerator示例，一次只产出一个结果，内存占用恒定，适合超大嵌套数组 - 对必须递归的场景，强制加缓存：用引用传参的
$cache数组记住已算过的输入输出，fibonacci($n, $cache)这种写法能把时间从 O(2^n) 压到 O(n)
递归函数里哪些操作最伤性能？
这些看似无害的写法，在递归中会被放大成瓶颈：
立即学习“PHP免费学习笔记（深入）”；
-
array_merge($path, [$k])：每次调用都新建数组，小数据不明显，树深 50 层时可能分配上万次小数组 - 在递归体里
json_encode($node)或print_r($node, true)：序列化整个子树，内存和 CPU 双爆炸 - 用
count($children)判断非空：不如直接!empty($node['children'])，前者要遍历计数 - 递归前不做 ID 类型转换：
$node['id'] === $targetId可能因字符串/整型混用导致全树匹配失败，白跑一遍
batch size 和 gc_collect_cycles 怎么设才有效？
分批不是靠猜，得看你的处理逻辑实际吃多少资源。比如写数据库：
- 每 100 条
PDO::beginTransaction()→ 批量INSERT→commit()，比单条提交快 10 倍以上 -
gc_collect_cycles()不是越多越好：只在明确知道有大量短期对象（比如临时数组、闭包）被创建后才调，比如每 500 次 yield 后调一次；频繁调用反而增加开销 - 真正关键的是「主动释放」：在递归函数末尾 unset 大变量，或用
unset($node)清掉不再需要的子结构引用，让 GC 有东西可收
复杂点在于：递归深度、数据密度、处理动作耗时三者耦合。没有银弹配置，必须用 memory_get_usage() 和 microtime(true) 在真实数据上测出来——否则 batch size 设再好，也挡不住一次 file_get_contents() 把内存拉满。
