启用 proxy_cache_lock 防缓存击穿需配合缓存区定义、key 控制和超时设置：先在 http 块定义 proxy_cache_path，location 中配置 proxy_cache、proxy_cache_lock、proxy_cache_lock_timeout 及 proxy_cache_key，再结合 stale 策略与 proxy_cache_valid 降低锁依赖。
直接启用 proxy_cache_lock 是防止缓存击穿最轻量、最原生的手段，但它不是“开就完事”的开关，必须配合缓存区定义、key 控制和超时设置才能真正起效。
必须先定义缓存区（proxy_cache_path）
该指令只能出现在 http 块中，是所有缓存功能的基础：
proxy_cache_path /var/cache/nginx/proxy_cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;-
keys_zone名称（如my_cache）后续会被proxy_cache引用，大小建议按每 1MB 支持约 8000 个 key 估算 -
use_temp_path=off可减少一次文件系统拷贝，提升写入性能
在 location 中启用锁并控制行为
只对缓存未命中（MISS）生效，其他情况（HIT/BYPASS）完全忽略：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
proxy_cache my_cache;—— 指定使用哪个缓存区 -
proxy_cache_lock on;—— 开启锁机制（默认是 off） -
proxy_cache_lock_timeout 5s;—— 等待锁释放的上限，超时后请求仍会回源；推荐设为 3–8 秒，太短易并发，太长拖慢用户
确保锁能真正覆盖目标请求
锁的作用范围由 proxy_cache_key 决定，相同 key 才共用一把锁：
- 默认 key 是
$scheme$proxy_host$request_uri，若 URI 含不同 query 参数（如/api/user?id=1和/api/user?id=2），就是两个独立锁 - 如需统一锁定某类接口，可自定义 key：例如
proxy_cache_key "$host:/api/user";，让所有用户请求共享锁 - 含动态 header（如
$http_x_user_id）或 cookie 的 key，会人为扩大 key 差异，削弱锁效果，需谨慎加入
搭配 stale 策略降低锁依赖
光靠锁不能解决全部问题，尤其在后端响应慢时。配合 stale 可显著缓解压力：
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;- 当后台正在更新缓存（updating）或出错时，Nginx 仍可返回旧缓存，用户无感知，也减少了新请求排队等锁的必要性
- 再配合
proxy_cache_valid 200 302 10m;给热点响应设合理有效期，从源头降低 MISS 频率
