proxy_cache_lock_age 是首个回源完成后禁止新回源的冷却期（默认5秒），防止缓存未稳时重复触发；它与 proxy_cache_lock_timeout 分阶段生效：前者控“写入后静默期”，后者控“等待首个结果最大时长”。
proxy_cache_lock_age 不是“等待超时”，而是“允许第二个回源请求触发的冷却时间”。它和 proxy_cache_lock_timeout 完全不同，作用机制容易混淆——调错会导致缓存更新变慢或并发回源激增。
明确 proxy_cache_lock_age 的真实作用
当第一个请求因缓存 MISS 触发回源并写入缓存后，Nginx 默认会“锁住”该 key 一段时间（默认 5 秒），期间即使缓存已写入、后续请求能直接 HIT，也不会放行新的回源请求。这个“锁住期”就是 proxy_cache_lock_age 控制的。
它的意义在于：防止在缓存刚写入但尚未稳定（比如响应头未完全校验、文件未刷盘）时，立刻有新请求因条件变化（如 header 差异、stale 判定不一致）再次触发回源。本质上是给缓存一个“安全沉淀窗口”。
- 值设得太小（如 1s）：刚写入就可能被新请求绕过，导致重复回源或 stale 响应被误判
- 值设得太大（如 30s）：在热点缓存频繁失效场景下，会人为拉长“只允许一个回源”的窗口，拖慢整体更新节奏
- 合理范围通常是 3–10 秒，具体取决于后端响应稳定性与缓存内容更新频率
与 proxy_cache_lock_timeout 协同配置
proxy_cache_lock_timeout 控制的是“等待首个回源完成的最大时长”，而 proxy_cache_lock_age 控制的是“首个回源完成后，多久内禁止第二个回源”。二者不是叠加关系，而是分阶段生效：
- 阶段一（MISS 初始）：多个请求同时到达 → 只放行第一个，其余等待 ≤
proxy_cache_lock_timeout - 阶段二（首个完成）：缓存写入成功 → 进入
proxy_cache_lock_age冷却期，期间新 MISS 请求仍会等待（而非立即回源） - 阶段三（冷却结束）：若此时缓存已过期或被清理，下一个请求才可再次触发回源
例如：proxy_cache_lock_timeout 5s; proxy_cache_lock_age 8s; 表示：等待最多 5 秒看第一个结果；一旦它完成，接下来 8 秒内即使缓存失效，也不允许新请求去回源——除非超时或主动 bypass。
高负载下需配合 stale 和 background update
单靠调整这两个 lock 参数无法解决高并发缓存更新压力。真正有效的组合是：
- 启用
proxy_cache_background_update on;：让缓存过期后继续服务旧内容，后台静默刷新 - 搭配
proxy_cache_use_stale error timeout updating http_502 http_503;：后台更新失败或卡住时，仍可用旧缓存顶住流量 - 把
proxy_cache_lock_age设为略大于典型后台更新耗时（如后台平均 4s，则设为 6s），确保背景更新有机会完成再开放新回源
这样既避免了用户等待，又限制了并发回源数量，比单纯拉长 lock timeout 更健壮。
验证是否生效的关键检查点
配置后不能只看日志有没有“LOCK”字样，要抓取实际行为：
- 用
$upstream_http_x_cache或自定义 header 输出HIT/MISS/EXPIRED/STALE状态，确认 MISS 是否被合并 - 观察后端 access log 中同一 URI 的并发请求数量是否明显下降（比如从 50+ 降到个位数）
- 检查 Nginx error log 是否出现
cache lock timeout，如有，说明proxy_cache_lock_timeout过短，而非lock_age问题 - 注意：若 upstream 返回了
Cache-Control: no-cache或配置了proxy_ignore_headers，lock 机制会直接跳过，需同步排查响应头控制逻辑
