Service Worker 是网络代理，负责拦截请求、离线缓存与推送；Web Worker 是计算线程，专注CPU密集型任务。二者定位不同、能力互补，需通过页面中转通信，不可互相替代。
Service Worker 和 Web Worker 都是 HTML5 提供的后台线程机制，但定位不同、能力不同、适用场景也不同。它们可以协作，但不能互相替代——混淆二者容易导致设计失误或功能无法实现。
核心定位差异：网络代理 vs 通用计算
Service Worker 本质是一个可编程的网络代理（network proxy），它运行在浏览器与网络之间，能拦截、修改、响应 fetch 请求，控制页面加载行为，并支持离线缓存、消息推送、后台同步等 Web App 核心能力。它不直接访问 DOM，也不属于页面生命周期的一部分，而是受浏览器独立管理。
Web Worker 是纯粹的 JavaScript 执行环境，用于将耗时计算任务移出主线程，避免阻塞 UI。它不能操作 DOM，也不能直接拦截网络请求，但可自由使用大量 CPU 资源进行数据处理、加密解密、图像分析等。
- Service Worker 的注册、激活、更新由浏览器严格控制，有明确的生命周期（install → waiting → active → redundant）
- Web Worker 由脚本显式创建（new Worker()），可随时终止（worker.terminate()），无内置持久化或唤醒机制
- Service Worker 可在页面关闭后继续运行（如处理 push 消息），Web Worker 在所属页面销毁时自动终止
通信方式不同：事件驱动 vs 消息传递
两者都通过 postMessage() 和 message 事件通信，但上下文和方向有明显区别：
立即学习“前端免费学习笔记（深入）”；
- Service Worker 与页面通信需通过 self.clients.matchAll() 查找目标 client，再调用 client.postMessage()；页面则用 navigator.serviceWorker.controller?.postMessage()
- Web Worker 通信更直接：页面持 worker 引用，可随时 worker.postMessage()；worker 内部用 self.postMessage() 回传
- Service Worker 无法直接向 Web Worker 发送消息，必须经由页面中转（页面作为“桥梁”）
典型协作场景：各司其职的组合模式
当应用需要“离线可用 + 高性能数据处理”时，两者常配合使用：
- 离线报表生成：Service Worker 缓存原始数据（如 JSON 文件），页面加载后触发 Web Worker 解析、聚合、生成图表数据，避免主线程卡顿
- 本地文件预处理：用户上传大文件，Service Worker 不参与；页面启动 Web Worker 进行分块哈希/压缩，完成后由页面通知 Service Worker 将结果缓存为新资源
- 消息推送+本地计算：Service Worker 接收 push 消息后，通过 clients.matchAll() 唤醒页面，再由页面启动 Web Worker 处理推送载荷（如解析日志、更新索引）
限制与避坑要点
协作中常见误用包括：
- 试图在 Service Worker 中 new Worker() —— 不被允许，会抛出异常
- 期望 Service Worker 直接访问 localStorage 或 indexedDB（虽支持，但应避免在 install 事件中阻塞操作）
- 忽略 Service Worker 的 HTTPS 限制（localhost 除外），导致开发环境正常、生产环境注册失败
- 在 Web Worker 中调用 fetch 时未意识到它绕过 Service Worker（除非在受控 scope 内且页面已激活 SW）
真正有效的协作，是让 Service Worker 管网络与生命周期，Web Worker 管计算与数据流，页面负责调度与桥接。
