proxy_cache_lock 通过串行化并发回源缓解缓存击穿，但需正确配置缓存区、统一cache key、设置合理超时与stale策略，并验证X-Cache-Status及后端日志确认生效。
proxy_cache_lock 本身不“解决”击穿，而是把并发回源压成串行，让后端只扛一次请求。要真正缓解热点资源突发访问带来的回源压力，必须让它在正确条件下稳定介入——不是配了就生效，而是每一步都得对上。
必须搭好缓存基础框架
没有缓存区，lock 就没地方落脚；没启用缓存，就压根不会触发 miss，锁自然形同虚设：
- 在 http 块 中定义缓存路径和共享内存区，例如：
proxy_cache_path /var/cache/nginx/proxy_cache levels=1:2 keys_zone=my_cache:512m inactive=3h use_temp_path=off;
其中keys_zone=my_cache是后续所有指令引用的名称，大小按每 1MB 支持约 8000 个 key 估算 - 确保磁盘路径存在，且 Nginx 进程有读写权限（macOS/Linux 下尤其注意目录 umask 或 SELinux 限制）
- 在目标 location 块 中明确启用缓存：
proxy_cache my_cache;
让锁真正锁定同一类请求
锁只认 cache key，key 不一样，就等于没锁。热点接口常因参数、header 或 cookie 差异被拆成多个 key，导致并发回源照旧发生：
- 默认 key 含
$args，/api/hot?id=1和/api/hot?id=2是两个独立锁 → 改用：proxy_cache_key "$scheme$host$uri";（剥离 query 参数） - 前端加随机参数（如
?t=1713086520或?v=2.3.1）也会破坏 key 一致性 → 同样通过自定义 key 忽略 - 带登录态的请求含 Cookie 或用户 header → 配合
proxy_ignore_headers Set-Cookie Vary;，并精简 key，避免混入身份信息
设置合理超时与 stale 回退策略
锁只管“等”，不管“等不来”。后端慢、失败或超时，等待中的请求不能干耗着：
-
proxy_cache_lock_timeout 5s;—— 推荐设为 3–8 秒
太短（如 1s），等待请求快速放弃锁，并发回源重现；太长（如 30s），用户明显卡顿 -
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
当首个请求回源出错、超时或正在更新时，后续请求可立即返回旧缓存，不排队也不穿透 - 延长热点响应有效期，从源头减少 miss：
proxy_cache_valid 200 302 30s;（API）或proxy_cache_valid 200 1h;（静态资源）
验证锁是否真实起效
别只看配置是否写对，要观测实际行为：
- 在 location 中加响应头：
add_header X-Cache-Status $upstream_cache_status; - 用
curl -I查看：首次应为X-Cache-Status: MISS，紧随其后的并发请求若返回HIT，说明锁成功复用结果；若仍是MISS，说明 key 不一致或配置未加载 - 压测验证：用
ab -n 20 -c 10请求同一 URL，检查后端 access log —— 开启 lock 后，应仅记录 1 条访问，而非 10 条
