proxy_cache_lock_timeout 控制等待队列最大时长，非避免挂起而是限制挂起时间；配合 use_stale updating、优化 cache_key 和缓存策略可大幅降低挂起感知与发生概率。
proxy_cache_lock_timeout 本身不“避免挂起”，而是控制挂起多久后主动退出等待——它解决的不是“要不要挂起”，而是“挂到什么时候为止”。真正减少锁竞争带来的挂起感知，关键在于让请求尽量不进入等待队列，或进入后能快速获得响应。
它不是防挂起，而是控挂起时长
当多个请求同时访问一个未缓存资源时：
- 第一个请求回源，Nginx 对该 cache key 加锁
- 后续同 key 请求默认进入等待队列（不立即回源）
-
proxy_cache_lock_timeout就是这个队列的“最大等待时间” - 超时后，Nginx 放行一个等待请求去回源（不是全部），其余继续等或按 stale 策略处理
所以，挂起无法完全消除，但可以大幅压缩其发生概率和持续影响。
缩短实际挂起时间的三项实操重点
-
把 timeout 设在后端 P95 响应时间附近
- 若后端 95% 的回源耗时 ≤ 4s，设
proxy_cache_lock_timeout 5s即可覆盖绝大多数场景 - 若 P95 达到 6s（如含 DB 查询或外部依赖），设
7s更稳妥，避免大量请求在第 5 秒就超时并发
- 若后端 95% 的回源耗时 ≤ 4s，设
-
用
proxy_cache_use_stale updating消除等待感
FastAPI Flask Proxy下载FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 加上这句配置后，哪怕首个请求还在回源中，后续请求也能立刻返回旧缓存（stale）
- 用户完全感知不到挂起，后端压力也大幅降低
- 示例：
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
-
从源头减少 MISS，让锁根本没机会被争抢
- 对静态资源（JS/CSS/图片）：
proxy_cache_valid 200 302 24h - 对带版本号的接口：用
proxy_cache_key "$scheme$host$request_uri"剔除?v=xxx类参数 - 对含时间戳、utm 参数的 URL：同样在 key 中忽略
$args，防止每个请求都生成新 key
- 对静态资源（JS/CSS/图片）：
验证是否真减少了挂起影响
在 location 中加一句：
add_header X-Cache-Status $upstream_cache_status;
然后并发请求同一未缓存路径，观察响应头：
- 出现
UPDATING→ 锁已生效，请求正在等缓存写入 - 出现
HIT（紧随MISS后）→ 等待成功，没挂住用户 - 大量
MISS连续出现 → key 不一致或proxy_cache_lock未真正启用
不复杂但容易忽略
