CDN 缓存时间怎么定：max-age、s-maxage 和 stale-while-revalidate 对收录的影响

新条目上线三天还没被收录，多数人的第一反应是「蜘蛛没来」。但日志一看，蜘蛛来了，拿到的是 CDN 上的旧副本，页面内容还是上周的。这种事在目录站上特别容易发生，因为列表页改动的频率远高于文章站，而缓存配一次就没人再动。

图片来源：网络，版权归原作者所有，侵权请联系删除

三个指令分别管谁

max-age 是最常用的那个，它同时约束浏览器缓存和共享缓存（CDN、代理）。s-maxage 只约束共享缓存，一旦出现，CDN 就以它为准，忽略 max-age。这个差别很关键：你可以让浏览器一分钟校验一次，同时让 CDN 缓存一天，两边互不干扰。

stale-while-revalidate（缩写 SWR）来自 RFC 5861，是 Nottingham 在 2010 年 5 月发的一份 informational 文档，定义了 stale-while-revalidate 和 stale-if-error 两个扩展。前者的意思是：过期之后的一段时间内，缓存仍然可以把旧副本直接返回给请求方，同时在后台去源站取新的。后者是源站返回 500、502、503、504 这类错误时，允许继续用旧副本顶上。

目录站各类页面的建议值

页面/资源	建议 Cache-Control	理由
首页	max-age=60, s-maxage=600	首页变动频繁，CDN 十分钟足够
分类页	max-age=300, s-maxage=3600	一小时内的新旧差别可接受
条目详情页	max-age=600, s-maxage=86400	内容稳定，可以放长一点
带 hash 的 JS/CSS	max-age=31536000, immutable	文件名变了就是新资源，永久缓存
sitemap.xml / robots.txt	max-age=3600	别让 CDN 默认策略把它缓存成一天以上
sw.js	no-cache	必须每次校验，否则更新推不下去

这张表不是标准答案，是起点。你可以按自己站的实际改动频率往上调或往下调，但先把「不同页面用不同值」这件事立起来，比给全站配一个统一值强太多。

过期不等于立刻被重新抓取

SWR 有个容易被忽略的性质：后台校验只有在过期后有请求进来时才会触发。文档里举的例子是 max-age=600, stale-while-revalidate=30，含义是前 600 秒直接用缓存，接下来的 30 秒内先把旧的给出去、后台悄悄取新的，30 秒过去还没有请求经过，那这份缓存就真成旧的了，下一个请求会阻塞等待回源。

对目录站来说，这意味着冷门分类页可能一直停留在旧版本。首屏热门页每秒都有人访问，永远是最新的；长尾分类页一天没几个人来，SWR 窗口过了也没触发校验，蜘蛛来拿到的还是几天前的列表。你以为问题在收录，其实问题在缓存刷新时机。

真正的解法是主动清除

靠过期时间等它自己更新，本质上是在赌流量。更稳的做法是给缓存打标签，内容变了就按标签清。Cloudflare 叫 Cache-Tag，Fastly 叫 Surrogate-Key，各家名字不同，思路一样：响应头里带上这个条目相关的标签，比如 Cache-Tag: listing-3821, cate-design，条目下架或者分类调整时，一次请求把带这个标签的所有缓存对象清掉，不用去数它到底落在哪些 URL 上。

清完之后一定要验。用 curl -sI 看响应头，Cloudflare 看 cf-cache-status 是不是 MISS、age 是不是回到 0，Fastly 看 x-cache。见过最典型的翻车是：清除请求发出去了，状态显示成功，一个小时后旧版本又回来了，因为源站自己还在吐旧内容。CDN 只是复制了源站的东西，源站没改，清多少次都没用。

两个必须记住的顺序

第一，改内容之前别急着清缓存。先把源站改好、确认源站返回的是新版本，再去清 CDN，顺序反了等于白干一遍。

第二，涉及下架的页面更要小心。如果某个条目页被 CDN 缓存成了 200，然后你把源站改成了 410，CDN 上那份 200 还会继续服务一段时间。这种涉及合规的下架，清除缓存要和改状态码同步做，最好清完立刻用不同地区的节点验证一次。

另外提醒一句：别用 Vary: User-Agent 去给爬虫和用户返回不同内容。一来它会把缓存切成很多份，命中率断崖下降；二来这种做法本身就踩在伪装内容的边缘上。真要区分，多用 CDN 的缓存键配置，少用 Vary。