前端 Service Worker fetch 拦截如何绕过不该缓存的请求

Service Worker 的 fetch 事件可以拦截页面和子资源请求，但不代表所有请求都应该进入缓存。更稳妥的做法是先判断请求方法、来源、路径和资源类型：非 GET、跨域、动态接口、账户页面和明确要求 no-store 的请求直接放行；只有同源静态资源才交给 Cache Storage。

绕过不该缓存的请求，关键不是在缓存命中后再补救，而是在 fetch 监听器最前面建立清晰的绕过清单。绕过分支不调用 event.respondWith()，浏览器就会继续执行原本的网络请求。

为什么要先建立 fetch 请求绕过清单

MDN 对 fetch 事件的说明是：主线程发起网络请求时，Service Worker 可以通过 respondWith() 提供缓存响应、合成响应或网络错误；如果处理器没有调用它，浏览器会照常发起原始网络请求。这正好给“绕过”留下了明确边界：不适合缓存的请求不要进入缓存策略，也不要为了统一代码而强行调用 respondWith(fetch(request))。

这里的“直接放行”不是拒绝请求，而是让浏览器保留原有的 fetch 行为。尤其是跨域请求，不要只看它能否返回响应就决定缓存；响应类型、CORS 配置和站点权限都可能改变可用性。

在 fetch 最前面实现可读的绕过判断

把判定单独写成函数，后续增加路径时不必改动缓存主体。下面的示例只让同源 GET 静态资源进入缓存分支，其他请求返回 true 后退出监听器。

const CACHE_NAME = "static-v3";

function shouldBypass(request) {
  const url = new URL(request.url);

  // 非 GET 请求可能改变服务端状态，不进入静态缓存。
  if (request.method !== "GET") return true;
  // 只处理当前站点资源，跨域请求交给浏览器和 CORS 规则。
  if (url.origin !== self.location.origin) return true;
  // 接口与账户页面通常包含实时数据或登录态。
  if (url.pathname.startsWith("/api/") || url.pathname.startsWith("/account/")) {
    return true;
  }
  // 调用方明确要求不缓存时，尊重 Request 的缓存意图。
  if (request.cache === "no-store") return true;
  return false;
}

self.addEventListener("fetch", (event) => {
  if (shouldBypass(event.request)) {
    // 不调用 respondWith，让浏览器继续原始网络请求。
    return;
  }

  // 页面导航先走网络，避免把带登录态的 HTML 当静态文件缓存。
  if (event.request.destination === "document") return;
  event.respondWith(cacheFirst(event.request));
});

判断函数里的路径只是示例，真正项目应按自己的接口前缀调整。不要用“URL 看起来像图片”作为唯一条件；请求方法、origin 和调用方的缓存意图同样重要。

静态资源缓存与动态请求应该怎样分开

缓存主体只处理已经通过绕过判断的请求。缓存命中就返回已有响应，未命中时访问网络；网络返回成功后要先 clone()，因为响应体通常只能消费一次，副本才适合写入 Cache Storage。

async function cacheFirst(request) {
  const cached = await caches.match(request);
  if (cached) return cached;

  // 网络响应要保留一份副本给缓存，原响应返回给页面。
  const response = await fetch(request);
  if (!response || !response.ok) return response;

  const copy = response.clone();
  const cache = await caches.open(CACHE_NAME);
  // 只有已经通过 shouldBypass 的静态请求才会走到这里。
  await cache.put(request, copy);
  return response;
}

这段策略的边界很重要：它不是“所有 GET 都缓存”。GET 的动态接口同样会被前面的路径规则绕过；如果项目还有搜索参数、用户身份或实时轮询接口，也应把它们列入绕过清单，而不是等出现旧数据后再追查。

缓存版本更新时怎么避免旧资源继续命中

缓存名称是资源版本的一部分。发布新的静态文件后，把 static-v2 改成 static-v3，并在 activate 阶段删除旧名称；这样新版本不会继续命中旧缓存。清理逻辑只删除自己维护的前缀，避免误删同一站点的其他缓存。

self.addEventListener("activate", (event) => {
  event.waitUntil(
    caches.keys().then((keys) => Promise.all(
      keys
        .filter((key) => key.startsWith("static-") && key !== CACHE_NAME)
        .map((key) => caches.delete(key)), // 只清理旧的静态资源缓存
    )),
  );
});

验证时分两条线看：Network 面板确认 /api/、账户页面和跨域资源仍然发出网络请求；Application 面板确认 Cache Storage 里只有预期的静态资源和当前版本名称。只看到“请求成功”还不够，还要确认响应没有被错误地持久化。

常见问题

不调用 respondWith 就一定不会被 Service Worker 影响吗？

就这个 fetch 处理器而言，不调用 respondWith() 时，浏览器会继续原始网络请求。其他 fetch 监听器仍可能存在，所以复杂项目要避免重复注册和多个处理器抢先接管同一请求。

为什么缓存接口的 GET 请求也可能是错的？

GET 只代表请求方法，不代表内容稳定。搜索、用户资料、库存和权限判断都可能使用 GET；应按路径、身份和实时性把它们放进绕过规则。

response.clone() 可以省略吗？

当同一个响应既要返回给页面又要写入 Cache Storage 时不要省略。响应体只能按流消费，先克隆一份给缓存，原响应保留给调用方。

清理旧缓存是不是每次 fetch 都做？

不需要。旧缓存清理适合放在 activate 生命周期事件中，并通过版本名称和前缀限定删除范围，避免把缓存维护逻辑混入每次请求。