javascript如何实现缓存策略_Service Worker如何管理离线资源

Service Worker是JavaScript实现缓存策略的核心,通过拦截请求、自定义响应及持久化存储支持离线访问;需HTTPS注册,经历install(预缓存)和activate(清理旧缓存)生命周期,并依资源类型选用Cache-First、Network-First或Stale-While-Revalidate策略。

JavaScript 中实现缓存策略,核心在于 Service Worker —— 它是运行在浏览器后台的独立脚本,能拦截网络请求、自定义响应逻辑,并持久化存储资源,从而真正支持离线访问和精细缓存控制。

Service Worker 的基本注册与激活

Service Worker 必须通过 HTTPS(本地 localhost 除外)启用。注册时需确保主页面 JS 中调用 navigator.serviceWorker.register(),并在回调中监听安装(install)和激活(activate)生命周期:

  • 在 install 阶段,通常用 caches.open() 创建缓存空间,并用 cache.addAll() 预缓存关键静态资源(如首页 HTML、核心 CSS/JS、logo)
  • 在 activate 阶段,可清理旧版本缓存(如遍历 caches.keys() 删除非当前版本名的缓存),避免缓存冗余
  • 注意:Service Worker 不会立即接管页面,首次注册后刷新一次才生效;若已存在旧 SW,需手动 skipWaiting 或触发 update() 才能更新

缓存策略:Cache-First、Network-First 与 Stale-While-Revalidate

实际请求处理中,常用策略由 fetch 事件监听器决定:

  • Cache-First:优先查缓存,命中则直接返回;未命中再发网络请求,并将响应存入缓存再返回。适合不常更新的资源(如第三方库、图标字体)
  • Network-First:先尝试网络请求,成功则更新缓存并返回;失败时 fallback 到缓存。适合内容时效性较强但需保底(如新闻列表页)
  • Stale-While-Revalidate:立即返回缓存内容(提升响应速度),同时后台发起网络请求更新缓存。用户无感知,缓存始终“稍旧但可用”

示例代码片段(Cache-First):

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(cached => {
      if (cached) return cached;
      return fetch(event.request).then(response => {
        const copy = response.clone();
        caches.open('v1').then(cache => cache.put(event.request, copy));
        return response;
      });
    })
  );
});

精准控制缓存范围与更新机制

不能全站一股脑缓存。应按资源类型或路径做策略分流:

  • 对 HTML 文件建议用 Network-First + fallback 页面,避免因 HTML 缓存导致 JS/CSS 版本错乱
  • 对带版本号或哈希值的静态资源(如 main.a1b2c3.js),可用 Cache-First 并长期缓存(max-age=31536000)
  • 对 API 接口请求,一般不缓存或仅短时间缓存(如 60 秒),必要时配合 ETag 或 Last-Modified 做条件请求
  • 可通过 event.request.destination 判断请求类型(script、style、image、document 等),实现差异化处理

调试与常见陷阱

开发阶段务必善用 Chrome DevTools 的 Application → Service Workers 面板:

  • 勾选 “Update on reload” 可强制每次刷新重装 SW,避免调试时被旧版卡住
  • 点击 “Skip waiting” 和 “Unregister” 方便快速重试生命周期
  • 注意:fetch 事件中无法访问 document、window 等 DOM 对象;所有缓存操作必须显式 await 或用 Promise 链理清异步顺序
  • 缓存键默认基于完整 URL(含 query 参数),?t=123 和 ?t=456 被视为不同条目,需提前 normalize 请求 URL