Web Worker适合单页重计算，Shared Worker用于多标签共享状态，Service Worker专用于网络代理与离线能力；三者均受同源限制、不可操作DOM、通信依赖结构化克隆。
选型关键看任务性质：Web Worker 适合单页重计算，Shared Worker 适合多标签共享状态，Service Worker 专用于网络代理与离线能力。
看任务是否绑定单个页面
如果逻辑只服务当前标签页，比如解析大文件、实时渲染图表数据、密码哈希运算——用 Web Worker。它和页面一对一绑定，页面关闭即销毁，无需担心跨页干扰。
- 创建简单：
new Worker('./calc.js') - 通信直接：主线程与 Worker 之间
postMessage/onmessage即可，不需端口管理 - 无共享需求：不能被其他页面访问，天然隔离
看是否需要多个页面协同
当多个同源标签页要共用一份数据或状态时，比如在线协作编辑的光标同步、多窗口播放器统一控制、登录态广播——Shared Worker 更合适。只要还有一个页面连接着，它就持续运行。
- 必须显式获取端口：
sharedWorker.port.start()，所有通信走该端口 - 需手动管理连接：每个页面通过
sharedWorker.port.postMessage()发送，监听port.onmessage - 注意生命周期：关闭所有关联页面后，浏览器才终止 Shared Worker
看是否涉及请求拦截或离线支持
如果目标是让网站支持离线访问、预缓存资源、后台消息推送、自定义 fetch 响应——只能选 Service Worker。它不与任何页面直接绑定，而是作为浏览器层的代理存在。
- 强制 HTTPS（本地开发仅限 localhost）
- 注册后需等待 install → activate 才生效，有明确生命周期钩子
- 不能访问 DOM，也不能用
localStorage或document.cookie，但可操作 Cache API 和 IndexedDB
共性约束不能忽略
三者都遵循同源限制，脚本必须与主页面协议、域名、端口完全一致；都不能操作 DOM、调用 alert 或访问 window；通信都靠结构化克隆，函数、Promise、DOM 节点无法传递；本地开发必须启用 HTTP 服务，不可用 file:// 协议。
