开启 fastcgi_cache_background_update 的作用是缓存过期时旧内容毫秒返回、新内容后台静默生成，需同时配置 fastcgi_cache_use_stale updating、稳定 cache key 和 fastcgi_cache_lock off，并配合后端识别 X-Updating: 1 跳过非核心逻辑。
开启 fastcgi_cache_background_update 本身不会提速，它真正的作用是让缓存过期时“不卡用户”——旧内容毫秒返回，新内容在后台静默生成。响应速度提升的感知，来自用户始终拿到缓存命中（HIT），而非等待后端重建。
必须配齐的三项基础配置
单独加 fastcgi_cache_background_update on; 没有效果，以下三者需同时存在：
-
启用 stale 回退策略：加上
fastcgi_cache_use_stale updating;，告诉 Nginx “缓存正在更新时，允许继续用旧缓存响应”。这是用户不感知延迟的前提。 -
缓存 key 必须稳定可复现：例如使用
fastcgi_cache_key "$scheme$request_method$host$request_uri";。若 key 中含随机参数、时间戳或 Cookie，后台刷新请求算出的 key 和前台不一致，新内容会写到错误位置，导致刷新失效。 -
关闭 cache_lock：设为
fastcgi_cache_lock off;。若开启 lock，后台刷新请求可能被前台请求阻塞，反而失去“后台”意义。
后端 PHP 需轻量配合
Nginx 后台刷新时会携带 X-Updating: 1 请求头（PHP 中为 $_SERVER['HTTP_X_UPDATING']），后端应据此做差异化处理：
- 检查该 header 是否为
"1"，若是，则跳过审计日志、消息通知、权限二次校验等非核心耗时逻辑； - 但数据查询、模板渲染、JSON 组装等核心输出流程必须完整执行——否则缓存写入的是空响应或错误内容；
- 避免依赖 session 或用户态数据生成缓存内容，防止缓存污染。
缓存时效与路径要合理匹配
background update 不是无限续命，需结合业务节奏设定：
-
fastcgi_cache_valid 200 5s;这类短时效（如 5 秒）适合高变动接口，确保后台刷新频率可控、压力分散； -
fastcgi_cache_path要提前定义好，保证磁盘空间和内存 zone（keys_zone）充足； - 对带参数、登录态、管理后台等敏感路径，用
fastcgi_cache_bypass和fastcgi_no_cache显式拦截，防止 stale 返回他人数据。
验证是否真正生效
加一行调试响应头：add_header X-Cache-Status $upstream_cache_status;
- 首次访问 → 响应头中出现
X-Cache-Status: MISS，随后变为HIT（说明缓存已写入）； - 等待缓存过期后再次访问 → 仍见
HIT，且响应时间极低（说明 stale + background update 已接管）； - 同时观察后端日志：应能看到一次无感知的后台请求（带
X-Updating: 1），且仅一次。
