关键在于启用proxy_cache_use_stale updating，配合proxy_cache_background_update on、proxy_cache_lock on及合理proxy_cache_valid和inactive时长，实现过期后秒级返回旧缓存并后台更新。
要让 Nginx 在缓存过期后仍秒级返回内容，同时后台悄悄拉取新版本，关键不是只开 proxy_cache_background_update on，而是整套配置协同工作——它本身不“自动生效”，必须靠其他指令共同兜底。
必须启用陈旧缓存响应能力
仅开启 background update，Nginx 默认仍会拒绝用过期内容响应请求。真正起作用的是这行：
-
必须显式写入：
proxy_cache_use_stale updating——这是核心开关，没有它，用户收不到旧缓存，后台更新也形同虚设； - 建议补全常见异常情形：
error timeout http_500 http_502 http_503 http_504，增强容错性； - 对静态资源路径错误等场景，可单独限制 404 缓存时长，例如：
proxy_cache_valid 404 10s，避免无效条目长期占位。
缓存生命周期要合理设定
后台是否及时刷新，取决于你如何定义“过期”与“清理”：
-
proxy_cache_valid 200 302 10m：给正常响应设明确有效期（如 10 分钟），太短导致高频刷新，太长则更新滞后； -
proxy_cache_path ... inactive=30m：该值应显著大于proxy_cache_valid（如设为 30 分钟），确保缓存条目在无访问时才被清理，不影响后台更新逻辑； - 对带哈希的静态资源（如
app.7f3a1d.js），可设更长有效期（如1h），因文件名变更即代表内容更新，无需频繁回源。
防止并发请求触发重复刷新
proxy_cache_background_update 本身不限流也不加锁，高并发击中同一过期 key，可能瞬间发起数百次后台请求：
-
proxy_cache_lock on：确保同一缓存 key 只有一个请求真正回源； -
proxy_cache_lock_timeout 5s：超时后不等待，直接走proxy_cache_use_stale返回旧内容； -
proxy_cache_lock_age 15s：锁释放后 15 秒内不再允许新更新，避免刚刷完又被抢锁重刷。
验证是否真正生效
上线后用几个简单方式确认效果：
- 加响应头观察：
add_header X-Cache-Status $upstream_cache_status，看到STALE表示正在用旧缓存 + 后台刷新中； - 用
curl请求两次，间隔略超proxy_cache_valid时间，第二次应立刻返回（状态码 200 +X-Cache-Status: STALE），且上游日志中只出现一次新请求； - 检查 Nginx error 日志，若频繁报
cache lock超时或磁盘写入失败，说明路径不可写或空间不足。
