fastcgi_cache_lock 的作用是将并发缓存未命中请求串行化：仅首请求回源，其余最多等待5秒后复用新缓存；需满足cache_path定义、location启用cache及明确开启lock三条件，且key统一、超时合理、stale兜底到位。
fastcgi_cache_lock 的作用不是“防止击穿”，而是把并发缓存未命中（miss）请求串行化：只让第一个请求回源生成缓存，其余请求在 Nginx 层等待最多 5 秒，等缓存写入后统一返回。它不能消除击穿，但能大幅降低后端瞬时压力——前提是 key 统一、超时匹配、兜底到位。
锁生效的前提条件
这个机制不会自动启动，必须满足三个硬性条件：
- 已在 http 块中正确定义 fastcgi_cache_path，例如：
fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=fcgi:256m inactive=30m use_temp_path=off; - 对应 location 中启用了缓存：
fastcgi_cache fcgi; - 同一 location 中明确开启锁：
fastcgi_cache_lock on;
缺任一环，配置就形同虚设，X-Cache-Status 会显示 BYPASS 或 MISS，而不是 HIT 或 UPDATING。
让锁真正“锁住”请求
锁按 cache key 生效，key 不一致 = 锁失效 = 并发照旧。常见导致 key 分裂的问题和对策：
- 默认 key 含 $args，/api/list?page=1 和 /api/list?page=2 就是两个 key → 改用 fastcgi_cache_key "$scheme$host$uri";（去掉查询参数）
- 前端加随机 ?t=123456789 或 ?v=2.1 → 在 key 中固定路径，如 fastcgi_cache_key "$scheme$host:/api/list";
- 响应含 Set-Cookie 或 Cache-Control: no-cache → 加 fastcgi_ignore_headers Set-Cookie Cache-Control;，避免缓存被跳过
等待不等于卡死：必须配好超时与退路
等待上限固定为 5 秒（不可调），若首个请求没在这时间内完成，其余请求会放弃等待、各自回源。所以关键不是“延长锁时间”，而是让首个请求大概率成功、失败时有备用方案：
- fastcgi_read_timeout 至少设为后端 P95 耗时 + 3～5 秒（比如 PHP 平均耗时 4 秒，建议设为 10s）
- 务必启用 stale 回退：fastcgi_cache_use_stale error timeout updating http_500;，这样即使首个请求出错或超时，后续请求也能返回旧缓存，不卡顿也不穿透
- 搭配 fastcgi_cache_valid 200 30s; 避免大量缓存同时过期，引发集中 miss
什么情况下该关掉 lock
不是所有接口都适合开锁。以下场景建议关闭 fastcgi_cache_lock：
- 后端存在长耗时操作（如导出 Excel、复杂搜索），且无法控制其执行时间
- fastcgi_read_timeout 设置偏小，而 PHP 实际执行常超时，导致锁释放前连接已断
- 业务要求强实时性，不能接受哪怕几秒的旧缓存（此时应改用 ESI 或细粒度缓存）
关锁后，可通过 fastcgi_cache_use_stale updating + background update + 更精细的 key 控制来缓解击穿压力。
