proxy_cache_lock 仅能缓解而非完美规避缓存击穿，需严格配置 proxy_cache_path、proxy_cache 和 proxy_cache_lock，并配合 proxy_cache_key 规范、stale 回退及合理超时等策略协同生效。
proxy_cache_lock 本身不能“完美规避”缓存击穿导致的源站崩溃，它只是缓解手段之一。真正起效的前提是配置严谨、行为理解准确，并必须搭配其他策略协同使用。
必须满足的基础配置条件
缺一不可，否则 lock 完全不生效：
- 在 http 块中明确定义
proxy_cache_path，包含keys_zone（如my_cache:10m），这是共享内存锁的载体 - 在 location 块中启用缓存：必须有
proxy_cache my_cache - 在同一 location 中开启锁：
proxy_cache_lock on - 确保请求确实触发了 cache miss——若响应头含
Cache-Control: no-cache、命中了proxy_no_cache规则，或 Nginx 判定为 bypass，则 lock 不介入
锁的作用范围与常见失效原因
它不是全局锁，只对「完全一致的缓存 key」生效。以下情况会导致并发回源照旧发生：
-
proxy_cache_key包含动态值：比如默认含$args，那么/api/user?id=1和/api/user?id=2是两个 key，各自独立锁 - 未统一 query 参数处理：前端加了随机
?t=1713086520或版本号?v=2.3.1，需用proxy_cache_key "$scheme$host$request_uri"显式剔除 - Cookie 或 header 差异：如登录态用户带
Cookie: session=abc，而游客无此 header，默认 key 会不同；应配合proxy_ignore_headers Set-Cookie和proxy_cache_key剥离无关字段
关键增强配置组合
单靠 lock 无法应对高并发 MISS 场景，需三者并用：
-
设合理超时：
proxy_cache_lock_timeout 5s（3–8 秒为宜）。太短，等待请求放弃锁直接回源；太长，用户感知明显卡顿 -
启用 stale 回退：
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504。当 lock 持有者回源失败或超时，后续请求可立即返回旧缓存，避免全部堆积或降级失败 -
延长热点缓存有效期：
proxy_cache_valid 200 302 10m或更长。MISS 越少，lock 竞争越弱；对 API 接口可设 30s，静态资源可设数小时甚至数天
验证是否真正生效
别依赖猜测，用实际观测确认：
- 在 location 中添加：
add_header X-Cache-Status $upstream_cache_status; - 用
curl -I查看响应头：首次请求应为X-Cache-Status: MISS，紧随其后的并发请求应出现X-Cache-Status: HIT（说明锁成功阻塞并复用结果）或仍为MISS（说明 key 不一致或配置未生效） - 查后端访问日志：用
ab -n 20 -c 10并发压测同一 URL，开启 lock 后后端应仅记录 1 条访问，而非 10 条
