Nginx 高级教程：怎么借助 fastcgi_cache_background_update 在后台悄悄刷新过期页面

启用 fastcgi_cache_background_update 实现后台静默刷新需三要素协同：启用 fastcgi_cache_use_stale updating 回退策略、确保 cache_key 稳定可复现、关闭 fastcgi_cache_lock；后端需识别 X-Updating: 1 跳过非核心逻辑但保留核心输出；缓存时效与路径配置须合理，配合调试响应头验证生效。

用 fastcgi_cache_background_update 实现“后台悄悄刷新”，本质是让用户完全感知不到缓存过期——旧内容毫秒返回，新内容在后台静默生成并写入缓存。它不是简单开个开关，而是一套协同机制。

必须配齐的三项基础配置

单独开启 fastcgi_cache_background_update on 不会生效，以下三者缺一不可：

• 启用 stale 回退策略：加上 fastcgi_cache_use_stale updating，告诉 Nginx “当缓存正被后台更新时，允许继续用旧缓存响应”——这是用户不卡顿的前提
• 缓存 key 必须稳定可复现：例如用 fastcgi_cache_key "$scheme$request_method$host$request_uri";，避免含时间戳、随机参数或用户 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 秒）适合高变动接口，确保后台刷新频率可控
• 缓存区本身要定义好：在 http 块中声明 fastcgi_cache_path，并保证磁盘空间和内存 zone（keys_zone）充足
• 避免对带参数、登录态或敏感路径启用缓存，用 fastcgi_cache_bypass 和 fastcgi_no_cache 显式拦截，防止 stale 返回他人数据

验证是否真正生效

加一行响应头便于调试：add_header X-Cache-Status $upstream_cache_status;

• 首次访问 → 返回 HIT（说明缓存已写入）
• 等待缓存过期后再次访问 → 仍见 HIT，且响应极快（说明 stale + background update 已接管）
• 同时观察后端日志：应能看到一次无感知的后台请求（带 X-Updating: 1）
• 若出现 MISSED 或明显延迟，大概率是 key 不稳、stale 未启用，或后端跳过了关键输出