Service Worker 的 Cache Storage API：实现离线优先（Offline First）架构的存储策略

各位开发者朋友，大家好！今天我们要深入探讨一个在现代 Web 开发中越来越重要的话题：如何通过 Service Worker 和 Cache Storage API 实现“离线优先”（Offline First）架构。

如果你正在构建一个对网络依赖度高、用户体验要求严格的 Web 应用——比如 PWA（Progressive Web App）、内容管理系统或移动优先的应用——那么你一定听说过“离线优先”这个概念。它不是一句口号，而是一种设计哲学：优先从本地缓存加载资源，只有当本地没有可用数据时才去请求网络。

这不仅能提升性能（减少延迟），还能显著改善用户体验（即使断网也能使用核心功能）。而这一切的核心，就是 Service Worker + Cache Storage API。

---

一、什么是 Service Worker？为什么它是离线优先的关键？

Service Worker 是一种运行在浏览器后台的脚本，它独立于网页主线程，可以拦截和处理 HTTP 请求、推送通知、后台同步等任务。它的最大优势在于：

• 无须用户交互即可运行
• 可控制网络请求流程
• 支持离线缓存与响应

但请注意：Service Worker 必须部署在 HTTPS 环境下（开发环境 localhost 默认允许）。

核心能力总结：

能力	描述
拦截请求	可以捕获所有 fetch 请求并决定返回什么
缓存管理	使用 Cache 对象进行资源存储和读取
生命周期可控	安装 → 激活 → 运行 → 卸载
离线能力	在无网络时仍能提供缓存内容

---

二、Cache Storage API 基础知识

Cache Storage 是浏览器提供的持久化缓存接口，属于 window.caches 对象的一部分。你可以把它看作是一个“命名的缓存容器”，每个缓存都有唯一的名称（如 'v1-static'）。

主要方法：

方法	功能
caches.open(cacheName)	打开或创建一个缓存对象
cache.put(request, response)	将请求/响应对存入缓存
cache.match(request)	查找匹配的缓存条目
cache.delete(request)	删除指定请求的缓存项
cache.keys()	获取当前缓存的所有 key 列表

✅ 注意：Cache Storage 不是 localStorage 或 IndexedDB，它专为 HTTP 资源设计，非常适合缓存静态资源（JS/CSS/图片）和 API 响应。

---

三、实战案例：构建一个简单的 Offline First PWA

我们来一步步搭建一个完整的例子，演示如何用 Service Worker 实现离线优先策略。

步骤 1：注册 Service Worker

首先，在你的主 HTML 文件中注册 Service Worker：

<!-- index.html -->
<script>
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(registration => console.log('SW registered:', registration))
    .catch(err => console.error('SW failed to register:', err));
}
</script>

然后创建 /sw.js 文件（注意路径要正确）。

---

步骤 2：编写 Service Worker 脚本（sw.js）

这是整个架构的核心逻辑：

// sw.js
const CACHE_NAME = 'offline-first-v1';
const urlsToCache = [
  '/',
  '/index.html',
  '/styles.css',
  '/app.js',
  '/images/logo.png'
];

// 第一步：安装阶段 —— 缓存静态资源
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => cache.addAll(urlsToCache))
      .then(() => self.skipWaiting()) // 强制激活新版本
  );
});

// 第二步：激活阶段 —— 清理旧缓存
self.addEventListener('activate', event => {
  const cacheWhitelist = [CACHE_NAME];
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cacheName => {
          if (!cacheWhitelist.includes(cacheName)) {
            return caches.delete(cacheName);
          }
        })
      );
    }).then(() => self.clients.claim()) // 接管所有客户端
  );
});

// 第三步：fetch 阶段 —— 实现离线优先策略
self.addEventListener('fetch', event => {
  const { request } = event;

  // 如果是导航请求（页面跳转），优先尝试从缓存获取
  if (request.mode === 'navigate') {
    event.respondWith(
      caches.match(request)
        .then(response => {
          // 如果缓存中有，则直接返回
          if (response) return response;

          // 否则尝试联网获取，并缓存结果（用于下次离线）
          return fetch(request).then(networkResponse => {
            const clonedResponse = networkResponse.clone();
            caches.open(CACHE_NAME)
              .then(cache => cache.put(request, clonedResponse));
            return networkResponse;
          }).catch(error => {
            // 如果网络失败，返回 fallback 页面（如果存在）
            return caches.match('/offline.html');
          });
        })
    );
  }

  // 其他请求（如 API、图片）也走类似逻辑
  else {
    event.respondWith(
      caches.match(request)
        .then(response => {
          // 如果有缓存，返回；否则走网络
          return response || fetch(request);
        })
    );
  }
});

这段代码实现了以下关键点：

策略	描述
安装时预缓存	所有静态资源提前缓存到 CACHE_NAME 中
导航请求优先缓存	用户访问页面时，先查缓存，再联网，最后 fallback
自动更新缓存	第一次联网成功后，自动将响应存入缓存
错误兜底机制	断网时返回 /offline.html（需提前缓存该文件）

---

四、进阶策略：更灵活的缓存规则设计

上面的例子适合简单场景，但在复杂应用中，我们需要更精细的缓存策略。以下是几种常见模式：

1. 时间戳 + 版本控制（推荐用于生产）

const VERSION = 'v2';
const CACHE_NAME = `app-${VERSION}`;

// 在 install 中加入版本标识
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME).then(cache => {
      return cache.addAll([
        '/', '/index.html', '/styles.css', '/app.js'
      ]);
    }).then(() => self.skipWaiting())
  );
});

这样每次发布新版本时只需改 VERSION，旧缓存会被自动清理。

2. API 数据缓存（带过期时间）

对于动态 API 请求（如 /api/posts），我们可以这样处理：

self.addEventListener('fetch', event => {
  const { request } = event;

  // 匹配特定 API 路径
  if (request.url.startsWith('/api/')) {
    event.respondWith(
      caches.match(request).then(cachedResponse => {
        // 如果缓存存在且未过期（假设我们标记了 TTL）
        if (cachedResponse && !isExpired(cachedResponse)) {
          return cachedResponse;
        }

        // 否则联网获取并缓存（带过期时间）
        return fetch(request).then(networkResponse => {
          const cloned = networkResponse.clone();
          caches.open(CACHE_NAME).then(cache => {
            cache.put(request, cloned);
            // 设置过期时间（这里简化为手动记录）
            cache.put(new Request('/meta/ttl'), new Response(JSON.stringify({
              url: request.url,
              expires: Date.now() + 5 * 60 * 1000 // 5分钟过期
            })));
          });
          return networkResponse;
        });
      })
    );
  }
});

function isExpired(response) {
  // 简单模拟：从 meta 缓存里读取过期时间
  // 实际项目建议用 IndexedDB 存储元数据
  return false; // 示例省略具体实现
}

3. 强制刷新策略（适用于新闻类内容）

// 检测是否强制刷新（例如用户点击了刷新按钮）
if (event.request.headers.get('pragma') === 'no-cache') {
  event.respondWith(fetch(event.request));
} else {
  event.respondWith(caches.match(event.request).then(resp => resp || fetch(event.request)));
}

这种策略可以让用户主动触发最新数据加载，而不影响默认的缓存行为。

---

五、最佳实践总结（表格形式）

场景	推荐策略	示例
静态资源（HTML/CSS/JS）	安装时一次性缓存	urlsToCache 数组
导航请求（页面跳转）	先缓存后网络，失败返回 fallback	event.respondWith(...match.then(...fetch...))
API 数据	缓存 + TTL 控制	使用 cache.put() + 自定义元信息
图片资源	缓存 + CDN 头部判断	cache.match(request) + response.headers.get('ETag')
用户手动刷新	忽略缓存	检查 pragma: no-cache
版本升级	使用不同缓存名	CACHE_NAME = 'app-v2'

---

六、调试技巧与注意事项

如何查看缓存？

打开 Chrome DevTools → Application → Cache Storage → 查看每个缓存的内容。

常见坑点：

问题	解决方案
缓存未生效	检查 Service Worker 是否已激活（状态为 “activated”）
缓存不更新	使用新版本缓存名（如 v2），旧缓存不会被清除
CORS 报错	确保目标资源允许跨域（CORS headers）
缓存污染	不要在缓存中存储敏感数据（如 token）
内存占用过高	定期清理旧缓存（如 activate 事件中删除旧版本）

---

七、结语：为什么你应该现在就开始用 Offline First？

随着移动端普及和网络不稳定性的增加，“离线优先”不再是锦上添花的功能，而是用户体验的基本保障。Service Worker + Cache Storage 提供了一套成熟可靠的工具链，让你可以：

✅ 构建真正的 PWA
✅ 提升首屏加载速度（首次加载后几乎秒开）
✅ 支持弱网甚至无网环境下的基础功能
✅ 减少服务器压力（缓存命中率高）

记住一句话：不是所有请求都必须走网络，有些时候，缓存才是最好的答案。

希望今天的讲解能帮你真正理解并落地 Offline First 架构。如果你觉得有用，请分享给团队成员，一起打造更健壮、更智能的 Web 应用！

🧠 最后小贴士：不要试图缓存所有东西！只缓存那些你确定会频繁访问、变化不频繁的数据。合理利用 Cache Storage，才能让它成为你项目的强大引擎。