视频业务对加载速度极其敏感，用户点开一个视频时，如果CDN边缘节点上的缓存刚好过期，请求就得回源站重新拉取，等待几秒的黑屏足以让用户流失。Stale-while-revalidate（简称SWR）就是为解决这类问题而生的缓存策略：它允许在缓存过期后的窗口期内，先向用户返回旧缓存，同时由CDN在后台悄悄刷新这份资源，下一次请求自然就能命中新鲜内容。这篇文章从原理、配置和实际落地三个层面，聊聊它在视频CDN中的具体用法。
一、Stale-while-revalidate的核心原理
要理解SWR，先得回顾标准的HTTP缓存模型。通常我们在Cache-Control头里设置max-age=3600，表示这份资源在3600秒内是新鲜的，浏览器或CDN节点可以直接使用缓存。一旦超过这个时间，缓存就进入过期状态，按照传统做法，下一个请求必须回源验证（配合ETag做协商缓存）或者完整回源拉取，用户在这个等待期内什么都看不到。
SWR在这个模型上增加了一个概念：过期容忍窗口。完整的响应头大概长这样：
Cache-Control: max-age=600, stale-while-revalidate=86400
这行头的含义是：资源在600秒内绝对新鲜；在600秒到600+86400秒之间，缓存虽然过期了，但仍然可以直接返回给用户，同时触发一次后台刷新；超过这个窗口，就必须回源了。对视频文件、封面图、播放列表这类内容来说，新旧版本之间的差异通常很小，甚至完全没有差异，让用户先看旧的，几乎不会造成任何感知上的问题。
这里的关键在于“后台刷新”这个动作。传统协商缓存是同步的：用户发请求，CDN拿着ETag去问源站，源站说没变就返回304，说变了就把新内容完整传回来，用户全程等待。而SWR把回源这件事从用户请求的关键路径上剥离出去了，第一个触发刷新的用户拿到旧缓存立即响应，刷新完成后，后续用户命中的就是新资源。这是一种用轻微的内容延迟换取显著响应速度的折中，非常适合内容更新不频繁但访问量大的场景。
二、视频CDN中的配置实践
在视频场景下，不同类型的资源适合不同的缓存策略，不能一刀切地全配SWR。可以把视频站的资源粗略分成几类：视频切片文件、封面海报、播放列表与元数据接口、站点静态资源。它们对时效性的要求差别很大。
视频切片通常采用HLS或DASH格式，文件名里一般带有版本号或序号，内容不可变，这类资源直接设置超长的max-age即可，比如max-age=31536000，根本不需要SWR。真正需要SWR的是那些“同名但内容会更新”的资源，比如某个固定URL的封面图、直播间详情页、频道页的聚合JSON等。以Nginx为例，一个典型配置如下：
location /api/channel/ {
proxy_cache mycache;
proxy_cache_valid 200 30s;
# 关键：允许在过期后5分钟内返回旧内容并后台刷新
proxy_cache_use_stale updating;
proxy_cache_background_update on;
add_header Cache-Control "max-age=30, stale-while-revalidate=300";
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://origin;
}这段配置里，proxy_cache_use_stale updating表示缓存刷新期间可以返回旧内容，proxy_cache_background_update on则开启了后台更新。配合起来，就实现了标准的SWR行为：过期缓存在刷新过程中依然可服务。需要注意，Nginx的开源版本对后台更新的支持有一些细节限制，如果使用的是云厂商CDN，通常在控制台的缓存规则里直接勾选“过期缓存兜底”或“回源期间返回旧缓存”这类选项即可，本质上是同一机制。
还有一个容易踩坑的地方：SWR窗口不要设得太长。曾经有团队把封面图的SWR窗口设成了7天，结果运营更换了视频封面，用户在整整一周内看到的都是旧图，投诉不断。经验值是SWR窗口设置在max-age的1到5倍之间比较稳妥，既保证了过期后的快速响应，又不会让内容滞后太久。对于时效性敏感的内容，宁可用短的max-age加短SWR，也不要长max-age加长SWR。
三、与几种常见缓存方案的对比
要真正理解SWR的价值，最好把它和几个替代方案放在一起比较。第一种是纯max-age方案：设置一个很短的TTL，比如10秒，靠频繁过期来保证新鲜度。缺点很明显，过期瞬间如果有大量并发请求打到边缘节点，回源会出现惊群效应，源站压力骤增；设置很长的TTL则相反，内容更新滞后严重，只能靠人工purge刷新。
第二种是purge主动刷新方案：内容更新时由业务系统调用CDN的刷新API清掉缓存。这种方式时效性最好，但对业务侵入较大，每一处内容更新都要记得调刷新接口，漏了就是线上事故。而且刷新瞬间同样会产生回源集中放大的问题。
第三种就是SWR。它的优势在于把过期后的行为变成“旧内容兜底、异步更新”，既没有惊群，也没有太长的新鲜度滞后。下面这张表总结了几种方案的差异：
| 方案 | 响应速度 | 内容时效性 | 源站压力 | 业务侵入 |
|---|---|---|---|---|
| 短max-age | 过期瞬间慢 | 好 | 高，易惊群 | 无 |
| 长max-age + purge | 快 | 最好 | 刷新时集中回源 | 高 |
| SWR | 始终快 | 轻微延迟 | 低，后台异步 | 低 |
可以看到，SWR在三个维度上取得了不错的平衡。当然它不是万能的，如果业务要求内容更新后立即对用户可见，比如支付结果、库存状态这类强一致数据，就不适合用SWR，老老实实走短TTL加协商缓存或者不缓存更安全。
四、落地时的注意事项与排查思路
部署SWR之后，监控指标要有针对性地调整。首先要关注边缘命中率：SWR生效后，用户视角的命中率会明显上升，因为过期缓存也算命中了，但CDN后台的回源请求依然存在，两者要分开看。可以通过响应头里的X-Cache-Status或者云厂商的缓存命中报表来区分HIT、STALE、EXPIRED、MISS几种状态，其中STALE状态的占比就是SWR实际发挥作用的程度。
其次要注意回源带宽。SWR并没有减少回源总量，它只是把回源从用户请求路径挪到了后台。对于大文件视频，如果误把SWR配在了不可变资源上，后台刷新会白白重复拉取一模一样的文件，浪费大量回源带宽。判断方法很简单：如果资源URL带版本号或哈希值，就不需要SWR；如果URL固定但内容会变，才是SWR的用武之地。
最后是排查思路。如果发现用户始终看到旧内容，先检查SWR窗口是不是设得过长；如果发现源站压力没降反升，检查是否开启了去重回源（很多CDN叫“回源合并”或request collapsing），没有去重的话，过期瞬间的大量并发请求会各自触发一次后台刷新，SWR的效果就大打折扣。把SWR、请求合并、合理的分层缓存这三件事配合好，视频CDN的体验和源站负载才能真正达到理想状态。
Stale-while-revalidateCDN缓存视频加速修改时间：2026-09-06 22:18:44