php递归函数中用static数组缓存结果是最轻量可控的方式：先检查static $cache[$n]是否存在，命中则直接返回，未命中才执行递归计算并存入缓存；键需唯一标识输入，避免重复计算，但需警惕缓存穿透、键生成开销、内存泄漏及并发写冲突等问题。
PHP递归函数里怎么用静态变量缓存结果？
直接在函数内部用 static 数组存结果，是最轻量、最可控的方式，适合单函数优化，不依赖扩展。
- 每次调用先查
static $cache = []是否已有$n对应的值，有就直接返回 - 没命中才执行递归逻辑，算完立刻写入
$cache[$n] = $result - 注意键必须能唯一标识输入：整数/字符串安全；对象或数组参数得用
serialize()或md5(json_encode($args))生成键 - 不要在循环中反复重置
static变量——它只初始化一次，跨调用持久存在
示例：function fib($n) { static $cache = []; if (isset($cache[$n])) return $cache[$n]; if ($n
什么时候该换 APCu 或 Redis 而不是用 static？
当缓存需要跨请求、跨进程共享，或者你希望统一管理过期、清理、监控时，static 就不够用了。
-
APCu适合单机部署：用apcu_store('fib_100', $value, 3600)带 TTL，比static更易清理 -
Redis适合分布式或多服务共用场景：键名建议带命名空间，比如rec:fib:100，避免冲突 - 注意序列化开销：
apcu_fetch()和redis->get()返回的是原始类型，但复杂结构（如含资源句柄的对象）可能无法正确缓存 - 别忘了缓存穿透：对不存在的
$n（比如负数），也存个空值或特殊标记，防止反复击穿到底层计算
为什么加了缓存反而更慢？常见坑点有哪些？
缓存不是银弹，加错地方或方式不对，性能可能反降。
- 对无重复子问题的递归（比如遍历树状结构但每个节点参数都唯一），缓存键永远不命中，纯增开销
- 缓存键生成太重：每次调用都
json_encode()大数组，CPU 消耗可能超过计算本身 - 没设 TTL 或清理机制：缓存无限增长，内存泄漏，尤其
static变量在 CLI 长任务中会越积越多 - 并发写冲突：多个请求同时发现缓存未命中，都去计算，结果重复写入——APCu/Redis 本身线程安全，但业务逻辑需自行加锁或用原子操作
递归深度大时，光靠缓存还不够，还得做什么？
缓存解决重复计算，但压不住栈空间消耗。深度超 1000 层时，static 或 APCu 都救不了栈溢出。
- 优先考虑改写成迭代：用
while+ 显式栈（数组模拟）替代递归调用，彻底消除栈帧累积 - 若必须递归，用
ini_set('xdebug.max_nesting_level', 2000)（仅开发环境）或setrlimit(RLIMIT_STACK, ...)（CLI）临时放宽限制 - 尾递归在 PHP 中不被自动优化，改写成尾递归形式意义有限，不如直接转迭代
- 对超深结构（如嵌套 JSON 解析），用
yield生成器分批处理，把内存压力从栈转移到堆
真正要命的从来不是“要不要缓存”，而是先确认：这个递归里，哪些输入真的会反复出现？键是否稳定可复现？缓存生命周期和业务数据变更节奏是否匹配？这些比选哪个缓存后端重要得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
