workbox runtimecaching 是声明式运行时缓存配置入口，用于缓存构建时未知url的动态资源（如api、用户上传图片），不适用于js/css/html等静态资源；需按资源类型精准匹配urlpattern、指定handler（如networkfirst）、校验响应状态并设置cachename与插件。
Workbox runtimeCaching 是什么，什么时候该用它
runtimeCaching 是 Workbox 提供的运行时缓存策略配置入口，不是某个函数，而是一组预设缓存行为的声明式配置。它适用于「资源无法在构建时预知 URL（比如 API 请求、用户上传图片、动态生成的 JSON）」的场景。静态资源（JS/CSS/HTML）优先走 generateSW 的 precache，别混进 runtimeCaching 里——否则会浪费缓存空间，还可能因版本不一致导致离线失败。
常见误用：把所有 /api/ 请求都配成 StaleWhileRevalidate，结果后端返回了 401 或 500，缓存里却存了错误响应。缓存前必须检查响应状态。
怎么写一个安全的 runtimeCaching 配置
关键不是“怎么配”，而是“配哪些条件”。Workbox v7+ 要求每个规则必须含 urlPattern 和 handler，推荐用正则而非字符串匹配，避免误伤：
-
urlPattern 用 /^https?:\/\/api\.example\.com\/v1\//，不用 '/api/' —— 后者会匹配到页面里的 /api/status 内联脚本
-
handler 推荐 NetworkFirst 处理带身份凭证的请求（如含 credentials: 'include'），CacheFirst 仅用于只读、强一致性要求低的资源（如公开的头像 CDN）
- 务必加
options.cacheName，方便调试时在 DevTools → Application → Cache Storage 里快速定位
- 对 JSON 接口，加
plugins 过滤响应：plugins: [{
cacheWillUpdate: async ({ request, response }) => {
if (response && response.status === 200) return response;
return null; // 不缓存非 200 响应
}
}]
为什么 NetworkFirst 有时比 StaleWhileRevalidate 更稳
StaleWhileRevalidate 会立即返回缓存，再发网络请求更新缓存。但若用户首次访问，缓存为空，就会白屏或报错（尤其 React/Vue 水合时依赖接口数据）。而 NetworkFirst 在缓存未命中时直连网络，失败才 fallback 到缓存——前提是缓存里真有可用数据。
urlPattern 用 /^https?:\/\/api\.example\.com\/v1\//，不用 '/api/' —— 后者会匹配到页面里的 /api/status 内联脚本handler 推荐 NetworkFirst 处理带身份凭证的请求（如含 credentials: 'include'），CacheFirst 仅用于只读、强一致性要求低的资源（如公开的头像 CDN）options.cacheName，方便调试时在 DevTools → Application → Cache Storage 里快速定位plugins 过滤响应：plugins: [{
cacheWillUpdate: async ({ request, response }) => {
if (response && response.status === 200) return response;
return null; // 不缓存非 200 响应
}
}]
StaleWhileRevalidate 会立即返回缓存，再发网络请求更新缓存。但若用户首次访问，缓存为空，就会白屏或报错（尤其 React/Vue 水合时依赖接口数据）。而 NetworkFirst 在缓存未命中时直连网络，失败才 fallback 到缓存——前提是缓存里真有可用数据。
典型陷阱：
- 没配
cacheExpiration插件，缓存无限堆积，占用用户设备空间 - API 返回
Cache-Control: no-store，Workbox 默认尊重该 header，导致NetworkFirst也不存——需显式覆盖：plugins: [new workbox.expiration.ExpirationPlugin({ maxEntries: 50, purgeOnQuotaError: true })] - 跨域请求未设
crossOrigin: 'use-credentials'，Fetch 失败但没报错，静默降级到空缓存
调试 runtimeCaching 是否生效的三步检查法 别只看 DevTools 的 Network 标签页“Size”列显示 “(from service worker)”——那只是说明被 SW 拦截了，不等于进了缓存。
真实验证方式：
- 打开 Application → Cache Storage，找你配的
cacheName，看里面是否有条目、时间戳是否更新 - 在 Service Workers 标签页点 “Update on reload”，然后禁用网络（Offline 复选框），刷新页面，观察接口是否返回缓存内容
- 在 SW 文件里临时加
console.log('cached:', event.request.url)到fetch事件监听中（仅开发），确认拦截路径是否符合预期
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
