Cache-Control中stale-while-revalidate小于s-maxage的生效规则

针对你配置的响应头 public, s-maxage=3600, stale-while-revalidate=59，先给核心结论：
符合HTTP标准的缓存实现（浏览器、CDN、反向代理）不会忽略这个stale-while-revalidate（下文简称SWR）配置，它会正常生效，只是生效窗口较短，仅在缓存刚过期的59秒内触发异步重验证逻辑。网上流传的「SWR取值小于s-maxage就无效」的说法，本质是对SWR计时起点的认知错误。

两个参数的标准生效规则 #

以下是HTTP标准（RFC 5861、RFC 7234）定义的规则，主流CDN、浏览器缓存、Nginx代理缓存都按这个逻辑实现：

• s-maxage=3600：仅针对共享缓存（CDN、反向代理，浏览器私有缓存会忽略该参数）生效，定义响应的新鲜度周期为3600秒。从响应被缓存的时间点开始计算，3600秒内响应属于「完全新鲜」状态，所有命中缓存的请求直接返回缓存内容，不会触发任何回源动作。
• stale-while-revalidate=59：定义缓存新鲜度过期之后的59秒为SWR窗口。这个窗口内如果有请求命中缓存，缓存可以直接返回已过期的旧响应用户，同时后台异步发起回源请求拉取最新内容更新缓存，不需要让用户等待回源请求完成。

关键认知：SWR的计时起点是「缓存新鲜度到期的时间点」，而非「响应生成/被缓存的时间点」，和s-maxage的数值大小没有直接约束关系。

你当前配置的完整缓存行为时间线 #

结合你设置的参数，整个缓存生命周期的行为可以拆为三个阶段：

• 0~3600秒（新鲜期）：缓存完全新鲜，所有请求直接命中缓存返回，无回源，不触发SWR逻辑。
• 3600~3659秒（SWR窗口）：缓存已经过期，但仍在SWR生效窗口内。此时请求到达缓存后，会立刻返回旧的缓存内容，同时后台静默发起回源请求拉取最新版本更新本地缓存。用户不会感知到回源延迟，源站也不会因为缓存刚过期的突发请求被打穿。
• 3659秒之后（过期超窗）：缓存过期且超出SWR窗口，此时请求到达后，缓存会走同步回源逻辑，等待源站返回最新响应后再返回给用户，直到新响应被缓存，重新进入下一轮新鲜期周期。

常见误区说明 #

• 不存在「SWR取值必须大于s-maxage才生效」的规则。你当前配置的唯一效果是SWR窗口很短，只有缓存过期后的59秒内能做异步重验证，过了这59秒就必须同步回源，适合对内容实时性要求很高、只允许极短时间返回旧内容的场景。
• 如果你希望缓存过期后1小时内都可以返回旧内容异步更新，应该配置为s-maxage=3600, stale-while-revalidate=3600，此时SWR窗口为3600~7200秒，总缓存可服务时长为2小时。
• 部分老旧的非标准缓存实现可能错误地从响应生成时间开始计算SWR窗口，这种情况下你的配置确实会表现为SWR不生效，但这是实现bug，不是标准行为。

内容的提问来源于stack exchange，提问作者Gauri Padbidri