开启 fastcgi_cache_background_update 的核心价值是将“缓存过期→用户等待重建”变为“缓存过期→用户秒得旧内容+后台静默刷新”，显著降低 php-fpm 瞬时并发压力；需配合 fastcgi_cache_use_stale updating、fastcgi_cache_lock off、稳定 cache_key 及后端轻量响应（识别 x-updating: 1）才能生效。
开启 fastcgi_cache_background_update 的核心价值，是把“缓存过期 → 用户等待重建”变成“缓存过期 → 用户秒得旧内容 + 后台静默刷新”，从而显著降低后端 PHP-FPM 的瞬时并发压力。
避免请求排队击穿
默认情况下，缓存一过期，所有并发请求都会同时穿透到后端。若 50 个用户在毫秒级内访问同一页面，而 PHP-FPM 只有 10 个 worker，就会造成 40 个请求排队等待——CPU 和数据库连接被持续占用，响应延迟飙升。
启用 background update 后：
- 只有第一个过期后的请求触发后台刷新（非阻塞）
- 其余所有请求都立即返回陈旧缓存（
$upstream_cache_status显示 STALE） - 后端实际只多处理 1 次请求，而非 N 次
配合 stale 策略才能生效
单独开 fastcgi_cache_background_update on 不起作用。必须搭配：
-
fastcgi_cache_use_stale updating：允许 Nginx 在缓存正被后台更新时，继续用旧缓存响应用户 -
fastcgi_cache_lock off：防止 lock 机制反向阻塞后台刷新请求（二者逻辑冲突） - 稳定的
fastcgi_cache_key：例如"$scheme$request_method$host$request_uri"，确保前台与后台计算出的 key 完全一致
后端轻量响应是关键
Nginx 后台刷新请求会带 X-Updating: 1 头（PHP 中为 $_SERVER['HTTP_X_UPDATING'] === '1'）。此时后端应：
- 跳过审计日志、消息通知、权限二次校验等非核心耗时操作
- 但必须执行数据查询、模板渲染、JSON 组装等核心输出逻辑
- 避免读取 session 或用户 Cookie 生成缓存内容，防止缓存污染
时效与缓存区要匹配业务节奏
短缓存周期（如 fastcgi_cache_valid 200 5s）适合高变动接口，让后台刷新频率可控；长周期则削弱 background update 的价值。
同时确保：
-
fastcgi_cache_path设置足够大的keys_zone（如256m）和磁盘空间（如max_size=1g） - 用
add_header X-Cache-Status $upstream_cache_status验证：过期后仍见 HIT 或 STALE，且响应时间不变 - 对带登录态、敏感参数或 POST 请求，用
fastcgi_no_cache显式排除，不参与缓存
