Service Worker 架构：缓存策略与 Static Routing 原理

摘要

构建高可用 Web 应用的关键在于引入 Service Worker API。作为介于 Web 应用与网络之间的可编程代理，它为开发者提供了对网络请求拦截与本地资源缓存的精细化控制能力。

本文系统梳理了 Service Worker 的事件驱动生命周期、整洁架构 (Clean Architecture) 在离线应用中的落地模式，以及如何利用 W3C 崭新的 Static Routing API 消除传统的“启动开销 (Startup Penalty)”。

1. 核心原理与生命周期管理

Service Worker 运行于完全独立的全局作用域 (ServiceWorkerGlobalScope) 中，将其计算负载与 DOM 主线程隔离开来。这种设计禁止了直接操作 DOM 以及调用 localStorage 等同步 API。

1.1 生命周期关键阶段

注册 (Registration)：浏览器下载脚本并校验作用域 (scope)。若脚本内容与上一版本存在哪怕 1 字节的差异，即触发安装流程。
安装 (Installation / install)：专门用于预缓存 App Shell 静态资源的异步阶段。使用 event.waitUntil() 挂起安装，直至关键资源 Promise 全部 Resolve。
等待 (Waiting)：新版本安装完成后不会立即接管，需等待旧版标签页全部关闭，以确保应用状态一致性。
激活 (Activation / activate)：清理废弃缓存及旧版 IndexedDB 数据的最佳时机。
激活控制 (Active Control)：接管页面并持续监听 fetch、sync、push 等事件。

即时接管：通过在 install 事件中调用 self.skipWaiting() 以及在 activate 事件中调用 self.clients.claim()，可实现无需用户手动刷新的无缝升级。

2. 高级 Cache Storage 策略

与传统的 HTTP 协议缓存不同，CacheStorage API 提供了高度确定性、可编程的控制手段。

2.1 请求拦截模式 (Fetch Event)

Stale-While-Revalidate（先返回缓存，后台重新验证）：立即从缓存返回响应，同时在后台更新资源。适用于用户头像和社交 Feed 等场景。
Network First（网络优先，缓存回退）：优先确保数据的绝对新鲜度。网络不可用时降级使用本地缓存，适合实时数据仪表盘。
Cache First（缓存优先，网络回退）：为静态资源（JS/CSS 静态包、字体文件）提供最佳的加载性能。

2.2 不透明响应 (Opaque Responses) 处理

拦截非同源 (CORS) 资源且响应头缺乏开放策略时，将返回状态码为 0 的不透明响应。直接缓存此类响应存在风险，因为 Service Worker 无法感知内部是否为 404/500 错误，容易导致“缓存污染”。

3. POST 请求与 GraphQL 离线策略

Service Worker 面临的一个高级技术挑战是对非幂等请求的处理。CacheStorage 规范明确禁止直接存储 POST 请求的响应。而像 GraphQL 这类架构几乎将所有查询都收拢于单个 POST 端点，传统缓存策略在此类场景下彻底失效。

3.1 基于 IndexedDB 的持久化方案

为了使 GraphQL 查询支持离线访问，Service Worker 需将持久化介质转向 IndexedDB。具体做法是对请求体进行 Hash 计算以生成唯一的 Key：

async function handleComplexRequest(event) {
  const request = event.request.clone();
  const body = await request.json();

  // 忽略数据变更类 Mutation 操作
  if (body.query?.trim().startsWith('mutation')) {
    return fetch(event.request);
  }

  const cacheKey = await generateSHA256(JSON.stringify(body));
  const cachedData = await db.get(cacheKey);

  const networkPromise = fetch(event.request).then(async (res) => {
    if (res.ok) {
      const data = await res.clone().json();
      await db.set(cacheKey, data);
    }
    return res;
  });

  return cachedData || networkPromise;
}

该模式巧妙解耦了网络依赖，将 Service Worker 打造为本地数据的调度中枢。

4. 后台同步 (Background Sync) 与后台下载 (Background Fetch)

“离线优先”架构要求应用在弱网或断网环境下绝不丢失用户输入。

Background Sync：将表单提交、消息发送等原子操作托管给操作系统，一旦网络恢复（即便网页已关闭），自动在后台完成重试。
Background Fetch：专为大文件、多媒体等耗时下载/上传任务设计，能与操作系统的通知栏交互并提供暂停/取消控制。

5. 解耦架构：适配器模式与消息总线

在企业级应用中，Service Worker 应当被视作整洁架构 (Clean Architecture) 中的“基础设施适配器”。

5.1 基于通信总线的主动通知

当后台任务（如后台同步完成）执行完毕需要通知前端 UI 时，应使用解耦的消息通道 (BroadcastChannel 或 MessageChannel)：

// 在 Service Worker 内部
const channel = new BroadcastChannel('sw-events');
channel.postMessage({ type: 'SYNC_COMPLETE', payload: { count: 10 } });

// 在前端应用中
const channel = new BroadcastChannel('sw-events');
channel.onmessage = (event) => {
  if (event.data.type === 'SYNC_COMPLETE') {
    this.notifyUser(event.data.payload);
  }
};

6. 新一代进化：Service Worker Static Routing API

为了解决每次拦截请求都需要先唤醒 Service Worker 线程所带来的“启动延迟 (Startup Penalty)”，全新的 Static Routing API 允许在 install 事件中以声明式规则配置静态路由。

6.1 声明式原生路由

该 API 允许浏览器提前判断哪些请求无需经过 JavaScript 逻辑处理，从而直接避开 Service Worker 线程的启动开销：

self.addEventListener('install', (event) => {
  if (event.addRoutes) {
    event.addRoutes([{
      condition: { requestDestination: 'image', urlPattern: '/assets/*' },
      source: { cacheName: 'static-assets' } // 直接从缓存读取，无需唤醒 JS 线程
    }]);
  }
});

7. 性能优化与内存安全

常驻后台的特性要求开发者对内存泄漏保持高度警惕。例如全局变量引用未释放、未及时清理无用监听器等，都会严重影响浏览器性能。在上线前，利用 Playwright 等自动化工具在模拟离线环境（browserContext.setOffline(true)）下进行 E2E 测试是确保高可用性的必备步骤。

8. 总结

Service Worker 已经从最初单纯的拦截器演化为企业级系统中的核心基础设施。结合领域驱动设计并引入 Static Routing 等新的原生能力，即使在网络不稳定的情况下也能提供可靠的 Web 体验。

参考来源：W3C Service Worker 规范 (Candidate Recommendation)、Static Routing API 说明文档、MDN Web 文档。

摘要