proxy_cache_lock_age控制缓存刷新冷却期，防止高频重刷；它不决定客户端等待时长，真正控制等待的是proxy_cache_lock_timeout。
proxy_cache_lock_age 不是控制“等待响应”的参数，它管的是锁释放后多久才允许下一次更新尝试。很多人误以为它影响客户端等待时长，其实真正决定等待行为的是 proxy_cache_lock_timeout。lock_age 的作用是防止刚刷新完缓存，立刻又被另一个请求抢锁重刷——这在高并发热点场景下特别容易引发无效回源震荡。
proxy_cache_lock_age 的真实定位
它是一个“冷却期”机制，和锁本身无关，也不参与请求排队逻辑。它的值只在以下两个环节起效：
- 当前请求完成回源、写入缓存、释放锁之后
- 下一个同 cache key 的请求试图获取锁时，Nginx 会检查距离上次成功写入缓存是否已超过
lock_age秒
如果没超，该请求直接跳过锁逻辑（不等、不回源），转而走 proxy_cache_use_stale 流程（比如返回陈旧缓存）；如果已超，才重新进入锁竞争流程。
合理设置 proxy_cache_lock_age 的关键原则
-
必须大于等于
proxy_cache_valid设置的主缓存有效期：否则刚缓存生效就被判定“可刷新”，等于白设。例如proxy_cache_valid 200 5m，lock_age至少设为300s或略高（如330s）。 - 不宜过大：设成 10 分钟以上，可能让缓存长期无法更新，尤其当上游内容实际已变更但 Nginx 还在“冷却中”。
-
推荐值范围通常是
cache_valid × 1.1 ~ 1.5：比如缓存 2 分钟，lock_age设150s；缓存 10 分钟，设660s（11 分钟）。
配合 proxy_cache_lock_timeout 才能闭环
单设 lock_age 没用，必须和 lock_timeout 协同：
-
proxy_cache_lock_timeout 2s：客户端最多等 2 秒，超时就走 stale -
proxy_cache_use_stale updating：确保超时后能安全返回旧内容 -
proxy_cache_lock_age 330s：330 秒内不允许多次刷新，避免高频抖动
这样组合下来，效果是：
- 热点 key 在首次回源后，330 秒内所有新请求都直接返回旧缓存（不等、不争锁、不回源）
- 第 331 秒起，首个请求再次触发锁+回源，其余请求继续等或走 stale
- 整个过程对用户透明，后端压力被压到极低水平
实际配置片段（可直接用）
location /api/ {
proxy_cache my_cache;
proxy_cache_valid 200 5m;
proxy_cache_lock on;
proxy_cache_lock_timeout 2s;
proxy_cache_lock_age 330s;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
}
这个配置在模型下载、配置接口、首页 HTML 等典型热点路径上实测稳定，既防雪崩，又保新鲜度。
