proxy_cache_background_update 的作用是让 nginx 在缓存过期后立即返回旧内容并后台静默更新，而非主动异步刷新；它依赖 proxy_cache_use_stale updating 等配合，在请求命中 stale 缓存时触发单次后台回源，保证响应速度与缓存一致性平衡。
proxy_cache_background_update 的作用不是“实现异步更新”，而是让 Nginx 在缓存过期后，仍可立即返回旧缓存内容，同时在后台悄悄拉取新内容并更新缓存——它本身不触发更新，也不控制更新逻辑，只是改变缓存过期时的响应行为。
它如何工作：过期即用 + 后台刷新
启用该指令后，当请求命中一个已过期（stale）但尚未被主动刷新的缓存项时：
- Nginx 立即返回当前缓存内容（哪怕已过期），避免用户等待回源
- 同时，在后台发起一次与原始请求几乎相同的子请求（subrequest）到上游，获取新响应
- 若新响应有效（状态码 200/304 等、且满足 cache 条件），就用它原子性地替换旧缓存
- 整个过程对客户端完全透明，用户无感知
必须配合的关键配置
单独开启 proxy_cache_background_update on 是无效的，需同时满足：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- proxy_cache_use_stale updating：允许在缓存正在 background 更新时，继续使用旧缓存（这是“过期即用”的前提）
-
proxy_cache_valid 设置了缓存有效期（如
200 302 10m） - proxy_cache_lock off（推荐）：避免 background update 被 cache lock 阻塞；若开启 lock，background update 会被排队，失去“后台”意义
- 上游响应需带明确的
Cache-Control或Expires，或由proxy_cache_valid显式定义过期时间
实际效果示例
假设缓存有效期为 60 秒，用户 A 在 t=65s 发起请求：
- 缓存已过期 → 若未启用
updating，Nginx 会阻塞等待回源，用户等待 - 启用
use_stale updating+background_update on→ 立即返回 t=0~60s 缓存的内容，同时后台静默请求上游 - 用户 B 在 t=66s 请求同一资源 → 仍可能拿到旧缓存（除非后台更新已完成），同样不等待
- 后台更新成功后，后续请求才开始拿到新内容
它不是“定时刷新”，也不保证强一致
注意几个常见误解：
- 它不主动轮询或定时触发更新，只在有请求命中 stale 缓存时才触发后台 fetch
- 没有请求，就不会更新缓存（冷数据不会自动刷新）
- 多个并发请求命中同一 stale 缓存时，Nginx 默认只发起一次 background update（内部去重），不是每个请求都回源
- 更新失败（如上游超时、返回 5xx）不会影响已返回的 stale 内容，也不会报错，旧缓存继续保留
