Service Worker 技术详解：构建离线优先的现代Web应用-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00762/article/details/148575152

Service Worker 技术详解：构建离线优先的现代Web应用

ServiceWorker Service Workers 项目地址: https://gitcode.com/gh_mirrors/se/ServiceWorker

什么是Service Worker？

Service Worker是一项革命性的Web技术，它为开发者提供了对网络请求的精细控制能力。这项技术的诞生主要为了解决Web平台长期存在的几个核心问题：

HTTP缓存机制的黑盒问题：传统缓存机制对开发者不够透明
离线体验的构建难题：难以优雅地实现离线优先(Offline-first)的Web应用
后台执行环境的缺失：缺乏可靠的背景执行上下文

与历史上Gears、AppCache等声明式解决方案不同，Service Worker采用了命令式设计理念，将控制权完全交给开发者。

Service Worker的核心特性

Service Worker本质上是一种特殊类型的Web Worker，具有以下关键特征：

独立执行环境：运行在独立的全局脚本上下文中（通常在独立线程）
无页面绑定：不依赖于特定页面存在
无DOM访问权限：无法直接操作页面DOM

与普通Shared Worker相比的特殊之处：

独立存活：可以在无任何页面时继续运行
事件驱动：不活动时自动终止，需要时重新激活
明确的更新机制：支持版本控制和渐进升级
强制HTTPS：出于安全考虑仅限安全上下文使用

Service Worker的典型应用场景

离线应用：通过拦截网络请求实现离线访问
性能优化：智能缓存策略加速页面加载
后台功能：作为推送通知、后台同步等功能的基础

快速入门指南

注册Service Worker

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js').then(function(registration) {
    console.log('注册成功:', registration.scope);
  }).catch(function(error) {
    console.log('注册失败:', error);
  });
}

这段代码会注册一个控制/路径下所有页面的Service Worker。注意几个关键限制：

注册页面必须通过HTTPS提供服务（本地开发允许localhost例外）
Service Worker脚本必须与页面同源（但可通过importScripts引入其他源脚本）
作用域(scope)不能超过脚本所在路径

HTTPS的必要性

由于Service Worker能够拦截和修改网络请求，为防止中间人攻击，浏览器强制要求Service Worker必须在安全上下文中运行。

Service Worker生命周期

Service Worker脚本会经历三个阶段：

下载：获取脚本文件
安装：解析并执行脚本
激活：准备接管页面控制

开发者可以通过监听事件参与安装和激活过程：

self.addEventListener('install', function(event) {
  // 预缓存关键资源
  event.waitUntil(
    caches.open('v1').then(function(cache) {
      return cache.addAll(['/app.css', '/app.js']);
    })
  );
});

self.addEventListener('activate', function(event) {
  // 清理旧缓存
  event.waitUntil(
    caches.keys().then(function(cacheNames) {
      return Promise.all(
        cacheNames.filter(function(cacheName) {
          return cacheName !== 'v1';
        }).map(function(cacheName) {
          return caches.delete(cacheName);
        })
      );
    })
  );
});

event.waitUntil()方法接受一个Promise，用于延长生命周期事件。

控制页面流程

注册Service Worker后，页面不会立即被控制，需要刷新后才会生效。开发者可以通过以下方式检查控制状态：

if (navigator.serviceWorker.controller) {
  console.log('当前页面被Service Worker控制');
} else {
  console.log('当前页面未被控制');
}

特殊情况下，Service Worker可以调用self.skipWaiting()立即接管所有范围内的页面。

网络请求拦截

Service Worker的核心能力是拦截和处理fetch事件：

self.addEventListener('fetch', function(event) {
  console.log('拦截到请求:', event.request.url);
});

可以拦截的范围包括：

作用域内的页面导航请求
这些页面发起的任何子资源请求（包括跨域请求）

例外情况：

iframe和object元素会基于自身URL选择控制器
Service Worker自身的更新请求
Service Worker内部发起的请求（防止循环）

自定义响应

开发者可以完全控制响应内容：

self.addEventListener('fetch', function(event) {
  event.respondWith(
    new Response('<h1>Hello from Service Worker!</h1>', {
      headers: {'Content-Type': 'text/html'}
    })
  );
});

更常见的模式是使用缓存或网络回退策略：

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request).then(function(response) {
      return response || fetch(event.request);
    })
  );
});

缓存管理

Service Worker提供了专用的Cache API：

self.addEventListener('install', function(event) {
  event.waitUntil(
    caches.open('v2').then(function(cache) {
      return cache.addAll([
        '/',
        '/styles/main.css',
        '/scripts/app.js',
        '/images/logo.png'
      ]);
    })
  );
});

缓存匹配会考虑请求方法、URL和Vary头，但忽略新鲜度头信息。缓存项必须显式删除。

更新机制

Service Worker采用智能更新策略：

每次页面导航时检查脚本更新（字节对比）
发现更新后安装新版本，但旧版本保持控制
当所有使用旧版本的页面关闭后，新版本激活
旧版本被垃圾回收

这种设计避免了多个版本同时运行导致的复杂问题。

开发者可以监听更新事件：

self.addEventListener('install', function(event) {
  // 新版本安装中，旧版本仍在运行
  event.waitUntil(updateCache());
});

self.addEventListener('activate', function(event) {
  // 新版本已激活，可以执行清理工作
  event.waitUntil(cleanOldCache());
});