Service Worker设计缓存失败后的网络回退的实现方法

Service Worker 的网络回退不要写成“缓存没有就无条件 fetch”。更稳妥的 fetch 分支是：只接管同源 GET，请求先查 Cache，未命中再访问网络；网络返回成功响应时写入缓存，网络真正异常时再取预缓存的离线页。这样既保留浏览器对表单提交和跨域请求的默认处理，也不会把 404 当成网络异常。

核心判断是：缓存未命中不等于网络失败，HTTP 4xx/5xx 也不等于 fetch 抛错。只有网络请求被拒绝或离线等异常进入 catch；兜底链路必须最终返回一个 Response。

先把缓存命中与网络回退限定在 GET 请求

fetch 事件会覆盖受 Service Worker 控制页面及其子资源的请求。文章只处理可重复读取的同源 GET，不接管 POST、PUT、DELETE 等可能改变业务状态的请求，也不把跨域资源强行塞进同一个缓存策略。

用 respondWith 连接缓存、网络和离线兜底

respondWith() 必须在事件处理器同步执行期间调用，异步查缓存和请求网络可以放进它接收的 Promise。下面的实现把“接管范围”放在外层，把回退策略放进 handleGet()，阅读和排查都更容易。

const CACHE_NAME = "runtime-v1";
const FALLBACK_URL = "/offline.html";

self.addEventListener("fetch", (event) => {
  const { request } = event;
  const url = new URL(request.url);
  // 只接管同源 GET，避免改变表单提交和跨域请求的语义。
  if (request.method !== "GET" || url.origin !== self.location.origin) {
    return;
  }
  // respondWith 要同步调用，异步工作交给返回的 Promise。
  event.respondWith(handleGet(request, event));
});

async function handleGet(request, event) {
  // 先查缓存，命中后直接返回，减少网络依赖。
  const cached = await caches.match(request);
  if (cached) return cached;

  try {
    // 只有网络异常会抛错；404/500 仍然是正常 Response。
    const network = await fetch(request);
    // 只缓存成功的同源响应，避免把错误页写进运行时缓存。
    if (network.ok && network.type === "basic") {
      event.waitUntil((async () => {
        const cache = await caches.open(CACHE_NAME);
        // 缓存消费一份副本，原响应继续返回给页面。
        await cache.put(request, network.clone());
      })());
    }
    return network;
  } catch (error) {
    // 网络和缓存都不可用时，尝试返回预缓存离线页。
    const fallback = await caches.match(FALLBACK_URL);
    return fallback || new Response("网络暂时不可用", {
      status: 503,
      headers: { "Content-Type": "text/plain; charset=utf-8" }
    });
  }
}

外层判断保证非 GET 请求沿用浏览器默认网络流程。内层先执行 caches.match()，没有命中才调用 fetch()。注意，返回 404 或 500 时 network.ok 为假，但这不是异常；示例会把这个响应原样交给页面，而不会把它当成离线状态。

只缓存成功响应并保留原始响应体

Response 的 body 通常只能消费一次。cache.put() 会读取响应体，所以不能先把 network 放进缓存，再把同一个对象返回给页面；要把 network.clone() 交给 Cache，原对象留给 respondWith()。

示例还把写缓存放进 event.waitUntil()，让 Service Worker 知道这个异步写入属于当前事件。缓存名称使用版本化前缀，后续升级时可在生命周期代码中清理旧缓存；本篇不把 install/activate 混入回退分支。

缓存条件建议至少包括三层：请求是同源 GET、响应 network.ok 为真、响应类型适合当前缓存策略。对于带用户身份、短时效或强一致要求的接口，不应直接套用运行时缓存；即使技术上能缓存，也可能返回过期或越权数据。

用错误边界和复查信号防止回退失控

线上排查时不要只看“页面能否打开”。可以分别观察四类信号：缓存命中说明策略接管成功；缓存未命中后出现网络请求说明键或缓存版本不匹配；网络请求抛错后命中 offline.html 说明回退链完整；POST 请求没有进入自定义分支则说明放行条件仍在工作。

若离线页也不存在，最后的 503 Response 比让 Promise 继续 reject 更可控。若发现错误 HTML 被缓存，先检查是否遗漏 network.ok；若页面报 body 已读取，检查是否遗漏 clone()。如果每次都命中旧内容，再检查缓存名称、请求 URL 和清理旧缓存的生命周期逻辑，而不是继续扩大 catch。

• 缓存未命中：确认请求 URL、方法和缓存名称。
• 网络错误：确认是否真的进入 catch，不要把 404/500 混为断网。
• 回退失败：确认 offline.html 已被预缓存且路径同源。
• 数据风险：登录态、个性化和写操作接口默认不采用这套缓存策略。

常见问题

为什么 fetch 返回 500 没有进入 catch？

因为 HTTP 错误仍是成功完成的网络请求，fetch() 会返回一个 Response，只是 ok 为 false。只有网络层失败、请求被拒绝等情况才会抛出异常，所以应在拿到响应后显式判断 network.ok。

为什么写入 Cache 后页面读不到响应？

通常是同一个 Response body 被缓存写入和页面返回同时消费。把 network.clone() 传给 cache.put()，原始 network 继续返回即可。