Cloudflare 记录了Cache-Control标头的指令列表，包括重新验证时过时。
- stale-while-revalidate=
当存在于 HTTP 响应中时，stale-while-revalidate Cache-Control 扩展指示缓存可能会在它变得过时后提供它出现的响应，最多是自最初检索对象以来指示的秒数。
我将Cache-Control标头设置为public, max-age=0, stale-while-revalidate=30但我似乎从未收到缓存命中。Cloudflare真的支持这一点吗？
如果你把max-age=0，那么实际上什么都没有缓存，如果是这样，那么就没有什么可以服务的。尝试使用max-age=1- 这应该会在 30 秒内给出一些结果。
今天遇到了这个问题/问题，Cloudflare 文档不是很清楚，但在此页面的示例部分下有一个线索。
缓存控制：最大年龄=600，重新验证时陈旧=30
此配置指示资产在 600 秒内处于新鲜状态，并且在尝试初始同步重新验证时，可以向对同一资源的并行请求提供最多 30 秒的过时时间。
因此，Cloudflare确实支持该指令，但是它们的实现与人们预期的略有不同。从本质上讲，一旦缓存的内容过期，向服务器发出的第一个请求将导致对 Origin 的同步请求，该客户端必须等待(大多数人不希望的行为)。
但是，有一些支持，因为对同一资源的任何并行请求(例如由其他客户端发出)都将获得旧的/缓存的内容(带有CF-Cache-Status: UPDATING)。对此进行了测试，并能够确认行为。
这样，如果您的源响应非常慢，或者缓存资源非常流行，则只有一个客户端/用户被保留，其余的将从 Cloudflare 提供过时的缓存副本。聊胜于无。
不，Cloudflare 不支持stale-while-revalidate。他们的最后一句话是在 2022 年 1 月。
https://community.cloudflare.com/t/when-will-cloudflare-fully-support-stale-while-revalidate-with-asynchronous-background-revalidation/287764/9?u=dfabulich
首先，我们同意此功能对Internet有好处，我们将很快实施。目前不支持的原因是长期存在的技术债务造成的技术限制。好消息是，我们目前正在摆脱这些限制，以便我们可以安全地支持更多像这样的异步功能。同时，我感谢您的耐心等待，并期待尽快对此提供支持。
。从那以后，一切都没有改变。
Cloudflare 确实有一个功能，如果你眯着眼睛稍微转一下头，看起来有点像 SWR，在缓慢的重新验证期间，并行请求可以接收过时的UPDATING内容。但是该功能(真正有趣)默认处于打开状态，并且不受 SWR 标头的影响。(即使设置stale-while-revalidate=0也不会关闭该功能！
我在 2018 年写了一篇关于 Cloudflare 不存在的 SWR 支持的冗长分析，但它对我没有好处;Cloudflare从未直接回复过它。https://community.cloudflare.com/t/does-stale-while-revalidate-work/24161/6?u=dfabulich