fastcgi_cache_lock的作用是限制高并发回源：仅首个请求穿透至php，其余在nginx层等待最多5秒，待缓存生成后统一返回；需配合fastcgi_read_timeout、fastcgi_cache_valid和fastcgi_cache_use_stale updating才能生效。
fastcgi_cache_lock 的作用不是“应对高并发回源”，而是**限制高并发回源**：它让多个请求同时命中未缓存 URL 时，只放行第一个去 PHP，其余在 Nginx 层等待最多 5 秒，等缓存写入后统一返回。这不是万能开关，必须和后端响应速度、超时设置、缓存策略协同才有效。
锁生效的前提条件
配置 fastcgi_cache_lock on 后，它只在以下情况真正起作用：
- 请求命中同一个 cache key（需统一 fastcgi_cache_key，避免含随机参数、Cookie 或 Vary 头）
- 该 key 当前未缓存或已过期（由 fastcgi_cache_valid 和响应头共同决定）
- location 块中已启用缓存：fastcgi_cache my_zone; 且 my_zone 在 http 块中正确定义
- 未被 fastcgi_cache_bypass 或 fastcgi_no_cache 规则跳过
等待行为不可调，但可管理
所谓“等待 5 秒”是硬编码值，Nginx 源码中为常量 NGX_HTTP_FASTCGI_CACHE_LOCK_TIMEOUT，不存在 fastcgi_cache_lock_timeout 或 fastcgi_cache_lock_age 等指令。你不能延长或缩短这个时间，但可以控制它的后果：
- 若 PHP 实际耗时 ≤ 3 秒，5 秒等待基本不超时，锁能有效收敛并发
- 若 PHP 耗时常达 8 秒以上，第一个请求还没返回，其余请求就已超时放弃 → 锁失效，全部回源
- 此时应调高 fastcgi_read_timeout（至少比 PHP P95 耗时多 5 秒），并配合 fastcgi_cache_use_stale updating
防击穿不能只靠锁，要配 stale + background
单开 lock 只解决“同一时刻谁先回源”，但无法缓解用户等待感或后端慢导致的连锁失败。真正稳住高并发 miss 场景，需三者协同：
- fastcgi_cache_use_stale updating：缓存正在更新时，允许直接返回旧内容，用户无感知
- fastcgi_cache_background_update on：过期缓存由首个请求异步重建，其他请求继续读旧缓存
- fastcgi_cache_lock on（推荐）：防止多个请求同时触发后台更新，避免重复执行
哪些场景该关掉 lock
lock 不是默认最优解，对以下情况反而有害：
- 接口本身就很慢（如导出、聚合搜索），且无法提升 PHP 性能或延长超时
- 前端大量重试 + keepalive 复用，导致连接堆积、RST 断连、worker_connections 耗尽
- 缓存 key 设计混乱（如每请求带唯一 timestamp），锁根本无法复用
此时应关闭 lock，并转向更稳健的兜底：fastcgi_cache_use_stale error timeout http_500 http_503 + 更细粒度的缓存分层或后端限流。
