SWR策略通过Cache API实现“先返回缓存响应、再异步更新”，需在Service Worker中手动编排fetch与cache逻辑：GET请求优先返回缓存（含过期内容），同时后台拉取新数据并写入缓存，HTML/JSON推荐使用，CSS/JS宜用内容哈希，POST等非GET请求直接放行。
Cache API 配合 Stale-While-Revalidate（SWR）策略，核心是“先给旧数据、再悄悄更新”，不卡界面也不牺牲新鲜度。它不是 Cache API 自带的模式，而是靠你手动编排 fetch 与 cache 的时序逻辑来实现。
关键思路：分两步走，响应快 + 缓存新
SWR 的本质不是“缓存是否命中”，而是“缓存是否可用 + 是否需要后台刷新”。你需要在 fetch 事件中同时做两件事：
- 立刻返回缓存内容（哪怕已过期），避免白屏或 loading 卡顿
- 另起一个异步 fetch 请求拉取最新数据，并成功后写入缓存，为下一次服务
按资源类型决定是否启用 SWR
不是所有请求都适合 SWR。要结合 destination 判断：
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- HTML 文档（destination === 'document'）：推荐用 SWR，保证首屏结构快速渲染，再静默更新
- CSS / JS（destination === 'script' 或 'style'）：更适合 Cache-First + 内容哈希命名，避免版本错乱
- JSON 接口（destination === 'json'）：SWR 是首选，尤其首屏关键数据（如用户信息、商品列表）
- POST / PUT 等非 GET 请求：必须跳过缓存逻辑，直接 return fetch(event.request)
代码层面怎么写 SWR？
在 Service Worker 的 fetch 事件中，这样组织逻辑更稳妥：
立即学习“前端免费学习笔记（深入）”；
- 先检查 request.method === 'GET'，非 GET 直接放行
- 调用 cache.match(request)，拿到缓存响应（可能为 undefined）
- 无论有没有缓存，都立即 resolve 一个 Response（有缓存就返回它；没缓存就 fetch 并 await）
- 同时启动一个不阻塞的 fetch 请求，成功后用 caches.open().put() 更新缓存
- 注意 cache.match() 默认严格匹配 method 和 query 参数，如需宽松匹配，加选项 { ignoreMethod: true, ignoreSearch: true }
配合版本管理与缓存清理
SWR 要长期可靠，得和缓存生命周期协同：
- install 阶段预缓存 app shell 等静态资源，用 Cache-First
- activate 阶段遍历 caches.keys()，删除不匹配当前 CACHE_NAME 的旧缓存（比如从 'v1' 升级到 'v2'）
- 对不同接口设置差异化 staleTime（例如热搜榜 30 秒、用户资料 5 分钟），靠自定义逻辑判断是否“该更新了”
