开启 fastcgi_cache_background_update 后用户感觉不到缓存过期，因旧缓存毫秒返回、新内容后台静默更新；需同时配置 fastcgi_cache_use_stale updating、稳定 cache_key 和 fastcgi_cache_lock off，并配合后端识别 X-Updating: 1 头优化逻辑。
开启 fastcgi_cache_background_update 后，用户看到的不是“缓存刷新中”，而是“内容始终秒开”——旧缓存毫秒返回，新内容在后台静默生成并覆盖，全程无感知。
为什么用户感觉不到缓存过期？
关键在于 Nginx 不再让请求等待刷新，而是把“过期处理”从前台移到后台：
- 缓存未过期 → 直接返回（HIT）
- 缓存已过期但尚未被清理 → 仍立即返回旧内容（stale + HIT），响应时间不变
- 同时触发一次后台请求 → 带
X-Updating: 1头调用后端，生成新内容写入缓存
必须配齐的三项基础配置
单独打开 fastcgi_cache_background_update on 没有效果，缺一不可：
-
启用 stale 回退策略：加上
fastcgi_cache_use_stale updating，否则过期后请求会阻塞或返回 502/503 -
cache_key 必须稳定可复现：推荐
fastcgi_cache_key "$scheme$request_method$host$request_uri";，避免含 Cookie、时间戳、随机参数 -
关闭 cache_lock：设为
fastcgi_cache_lock off;，否则后台刷新可能被前台请求锁住，失去“后台”意义
后端 PHP 需要轻量配合
Nginx 后台刷新时会发送 X-Updating: 1 请求头（PHP 中对应 $_SERVER['HTTP_X_UPDATING'] === '1'），后端应据此做差异化处理：
- 跳过审计日志、消息推送、权限二次校验等非核心耗时逻辑
- 但必须执行数据查询、模板渲染、JSON 组装等核心输出流程
- 避免依赖 session 或用户态数据生成缓存内容，防止缓存污染
缓存时效与路径配置要合理
background update 不是延长缓存寿命的万能药，需匹配业务节奏：
-
fastcgi_cache_valid 200 5s;适合高变动接口，确保后台刷新频率可控 - 在
http块中定义充足空间的缓存区：fastcgi_cache_path /var/cache/nginx/fastcgi ... keys_zone=my_cache:100m max_size=1g; - 用
fastcgi_cache_bypass和fastcgi_no_cache显式排除登录态、带敏感参数或个性化路径
如何验证是否真正生效？
加一行调试头：add_header X-Cache-Status $upstream_cache_status;
- 首次访问 → 响应头含
X-Cache-Status: MISS，随后变成HIT - 等待缓存过期后再次访问 → 仍见
HIT且响应极快（说明 stale + background update 已接管） - 检查后端日志 → 应能看到一次带
X-Updating: 1的额外请求，时间戳略晚于用户请求
