proxy_cache_lock 通过串行化同 key 请求防雪崩，但需配合缓存区定义、统一 cache key、合理超时及 stale 机制才能真正稳住后端；缺失任一环节，锁即失效。
proxy_cache_lock 本身不“防范雪崩”，它只在缓存未命中（MISS）时，把同一 cache key 的并发请求串行化——仅放行第一个去回源，其余等待结果写入后直接读缓存。真正稳住后端的，是一整套协同配置：缓存区必须存在、key 必须统一、超时必须合理、失败必须有退路。
缓存基础必须搭牢
没缓存区，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 进程有读写权限（Linux/macOS 下注意 SELinux 或 umask 限制）
- 在目标 location 中明确启用缓存：
proxy_cache my_cache;
这是 lock 生效的硬前提
锁要真正锁住同一类请求
锁按 cache key 绑定，key 不一致，就等于没锁。热点接口常因参数、header 或 cookie 差异被拆成多个 key，导致并发回源照旧发生：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 默认 key 包含
$args，/api/hot?id=1和/api/hot?id=2是两个独立 key → 改用：proxy_cache_key "$scheme$host$uri";（剥离 query 参数） - 前端加随机参数（如
?t=1713086520或?v=2.3.1）也会破坏一致性 → 同样通过自定义 key 忽略 - 带登录态的请求含 Cookie 或用户 header → 配合
proxy_ignore_headers Set-Cookie Vary;，并精简 key，避免混入身份信息
设好等待底线与失败兜底
锁只管“等”，不管“等不来”。后端慢、失败或超时，等待中的请求不能干耗着：
-
proxy_cache_lock_timeout 5s;—— 推荐设为 3–8 秒
太短（如 1s），等待请求快速放弃锁，并发回源重现；太长（如 30s），用户明显卡顿 -
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
当首个请求回源出错、超时或正在更新时，后续请求可立即返回旧缓存，不排队也不穿透 -
proxy_cache_valid 200 302 30s;（API）或proxy_cache_valid 200 1h;（静态资源）
延长热点响应有效期，从源头减少 MISS 次数
验证是否真实起效
别只看配置是否写对，要观测实际行为：
- 在 location 中加响应头：
add_header X-Cache-Status $upstream_cache_status; - 用
curl -I发起两次紧邻请求：
首次应为X-Cache-Status: MISS，第二个请求若返回HIT，说明锁成功复用结果；若仍是MISS，说明 key 不一致或缓存未启用 - 压测时观察上游 QPS：模拟 100 并发访问同一未缓存资源，开启 lock 后，后端 QPS 应稳定在 1 左右，而非飙升至百级
