stale-while-revalidate是HTTP响应头指令，需服务端在Cache-Control中设置（如max-age=60,stale-while-revalidate=300），现代Chrome/Firefox支持，HTML的meta标签无效，且仅对document/json请求生效。
stale-while-revalidate 不是 HTML 能“实现”的策略，它是一个 HTTP 响应头指令，必须由服务端在 Cache-Control 中设置，浏览器（仅现代 Chrome/Firefox）才会按规范执行。HTML 本身不参与缓存逻辑，也不提供 API 控制该行为。
Cache-Control 响应头必须由后端设置
stale-while-revalidate 的生效前提是服务端返回类似这样的响应头：
Cache-Control: max-age=60, stale-while-revalidate=300
-
max-age=60：资源新鲜期为 60 秒 -
stale-while-revalidate=300：过期后 5 分钟内，仍可直接返回缓存，并后台发起 revalidation 请求
你无法在 HTML 文件里通过 <meta> 或 JS 模拟这个行为——<meta http-equiv="Cache-Control"> 在现代浏览器中完全被忽略，仅对极老版本 IE 有效，且不支持 stale-while-revalidate。
浏览器支持有限，且仅作用于特定请求类型
stale-while-revalidate 当前（2026 年）仅在以下条件下生效：
立即学习“前端免费学习笔记（深入）”；
- ✅ Chrome ≥ 75、Firefox ≥ 115（含 ESR）
- ❌ Safari、Edge（基于 Chromium 的新版 Edge 虽底层支持，但部分版本因策略限制未启用）
- ✅ 仅对
destination === 'document'或'json'的 fetch/XHR 有效（如fetch('/api/data')） - ❌ 对
<script>、<link rel="stylesheet">、<img>等资源不生效（规范未覆盖这些 destination）
你在 DevTools Network 面板中能看到两个请求：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 一个
200 (from cache)（立即返回陈旧数据） - 一个并发的
304 (from memory cache)或200（后台验证）
但前提是服务端响应头正确，且请求满足 destination 条件。
常见错误：误以为前端能“开启 SWR”
开发者常踩的坑包括：
- 在 HTML 中写
<meta http-equiv="Cache-Control" content="max-age=0, stale-while-revalidate=60">→ 无效 - 用
fetch()加cache: 'force-cache'试图触发 SWR → 不触发后台 revalidation，也不读 swr 窗口 - 期望 Service Worker 拦截并模拟 SWR 行为 → SW 可模拟，但不是标准 SWR；需手动实现缓存+后台更新逻辑，且无法复现原生的“自动并发 revalidate”语义
真正可控的替代方案只有：
- 后端配置 CDN 或反向代理（如 Nginx、Varnish）输出正确
Cache-Control - 前端用 TanStack Query / SWR / swrv 等库在 JS 层模拟 SWR 语义（与 HTTP 层无关，纯客户端状态管理）
最容易被忽略的一点
stale-while-revalidate 是单次窗口策略：只对缓存过期后的「第一次」请求生效。第二次请求若仍在 swr 窗口内，返回的是第一次 revalidation 后的新缓存（即已刷新过的“新鲜”缓存），不再触发新后台请求。
这意味着它不等于“持续轮询”，也不是“永远返回旧数据”。它的价值非常具体：消除首屏卡顿感 + 保障后续请求始终有可用缓存。但前提是你得让服务端真正发出那个头——HTML 什么都做不了。
