Nginx 可通过 map 指令动态设置 proxy_cache_valid 缓存时长，依据路径、Referer、User-Agent、Content-Type 或自定义请求头等热度信号实时调整，需按优先级顺序匹配正则并设 default 值，配合 cache_key、限流与缓存锁提升稳定性。
静态资源突发热度（比如某张海报图被转发爆了、某个 JS 文件因活动上线瞬间请求激增）容易打垮后端，单纯固定缓存时间不够灵活。用 map 指令动态调整 proxy_cache_valid，可让 Nginx 根据资源类型、请求频率甚至路径特征，实时延长或收紧缓存时长，缓解源站压力。
识别高热度资源的触发信号
不能只靠文件后缀，要结合真实访问行为。常用信号包括：
-
请求路径含热点标识：如
/hot/、/promo/、/v2026/这类人工标记的路径前缀 - Referer 或 User-Agent 异常集中：比如大量请求来自同一社交媒体域名，或短时内同一 UA 频繁刷某 CSS
-
响应 Content-Type 明确且稳定：如
image/webp、application/javascript，这类资源天然适合缓存，且更新不频繁 -
请求头带自定义热度标记：上游服务可在突发时主动加
X-Hot-Resource: true，Nginx 用$http_x_hot_resource捕获
用 map 构建热度感知的缓存时间变量
在 http 块中定义映射，优先匹配热度信号，再回落到常规策略：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
map $request_uri $cache_ttl {
~*/hot/|/promo/|/v2026/ "24h"; # 热点路径直接拉长到1天
~*\.(js|css|webp|png|jpg)$ "1h"; # 常规静态资源1小时
~*^/static/.*\.(js|css)$ "7d"; # /static/ 下的 JS/CSS 更激进
default "10m"; # 兜底，避免空值
}注意：正则按顺序匹配，热度规则必须写在通用规则之前；default 不可省略，否则未匹配时变量为空，proxy_cache_valid 会报错或退回到全局默认值。
在 location 中启用并验证热度缓存
确保反向代理 location 启用了缓存，并正确引用变量：
- 开启缓存区：
proxy_cache my_static_cache; - 绑定动态时效：
proxy_cache_valid 200 302 $cache_ttl;（必须显式列出状态码） - 防 key 冲突：
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args$cache_ttl";（加入变量可隔离不同热度等级的缓存） - 调试用：
add_header X-Cache-TTL $cache_ttl always;，curl 查看响应头确认是否命中预期值
配合限流与降级更稳妥
单靠延长缓存还不够，建议叠加保护机制：
- 对热点路径加简单限流：
limit_req zone=hotburst burst=100 nodelay;，防爬虫误伤 - 设置缓存锁：
proxy_cache_lock on; proxy_cache_lock_timeout 3s;，避免缓存失效瞬间大量回源 - 当热度退去，可通过上游返回
Cache-Control: no-cache或 Nginx 的proxy_cache_bypass $http_x_hot_resource;主动跳过缓存
