要让 proxy_cache_lock 真正生效，必须同时满足四个条件：定义缓存区（proxy_cache_path）、启用缓存（proxy_cache）、统一 cache key（如 proxy_cache_key "$scheme$host$request_uri"）、显式开启锁并设合理超时（proxy_cache_lock on 与 proxy_cache_lock_timeout）。
要让 proxy_cache_lock 真正生效——即同一缓存 key 的大量并发请求中，仅首个透传到后端，其余排队等缓存写入后直接返回——必须满足四个硬性条件：缓存区已定义、缓存已启用、key 完全一致、锁机制明确开启。缺一不可，否则配置形同虚设。
缓存基础必须搭牢
没有缓存上下文，proxy_cache_lock 就像给没门的房间装锁。
- 在
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是后续所有指令引用的名称；use_temp_path=off避免临时文件拷贝，提升写入一致性。 - 确保磁盘路径存在，且 Nginx 进程有读写权限（注意 SELinux、umask 或容器挂载限制）。
- 在目标
location中必须启用缓存：proxy_cache my_cache;
没这句，Nginx 不走缓存流程，根本不会触发 MISS，lock 自然不启动。
cache key 必须严格统一
锁按 key 绑定，key 不一致 = 多把锁并行 = 白配。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 默认 key 包含
$args，/api/user?id=1001和/api/user?id=1002就是两个独立 key，各自回源。 - 对热点接口，显式收窄 key，例如：
proxy_cache_key "$scheme$host$request_uri";
它忽略全部 query 参数（如?t=123、&v=2.3.1），防止干扰。 - 务必排除动态字段：
不带$cookie_session、$http_x_trace_id等；
加proxy_ignore_headers Set-Cookie;，避免响应因带 Cookie 被跳过缓存。
锁机制必须显式开启并设合理超时
只开 on 不够，超时值决定系统是否卡顿或失效。
- 在同个
location中启用锁：proxy_cache_lock on; - 设置等待上限：
proxy_cache_lock_timeout 5s;
推荐值 3–8 秒，设为后端 P95 响应时间的 1.2–1.5 倍（例如 P95 是 2.4s，设 3s）；太短 → 大量超时后并发回源；太长 → 用户明显卡顿。
必须配容错退路，否则排队等于堵死
数万请求干等一个慢查询？不行。得允许“先返回旧缓存，后台悄悄更新”。
- 启用降级策略：
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
关键在updating：首个请求正在回源时，后续请求立刻返回过期缓存，不卡、不穿透。 - 延长有效时间，从源头减少 MISS：
proxy_cache_valid 200 302 30s;
对 API 接口足够抗瞬时洪峰；静态资源可设为 1h+。 - （可选）开启后台静默刷新：
proxy_cache_background_update on;
让首个请求写完缓存后，后台自动刷新，不影响用户响应。
