Worker由主线程直接实例化并terminate()立即终止；SharedWorker由所有引用页面共享，卸载时自动关闭；ServiceWorker由浏览器托管，通过register/unregister及事件钩子间接控制。
浏览器提供了专门的 API 来统一管理 Worker、SharedWorker 和 ServiceWorker 的生命周期，但三者机制差异大，不能套用同一套代码逻辑。关键在于区分「主动控制权归属」：普通 Worker 由主线程完全掌控；SharedWorker 由所有引用它的页面共享控制；ServiceWorker 则由浏览器在后台自主调度，主线程只能间接影响。
Worker：主线程直接实例化 + 显式终止
这是最直观的线程管理方式。创建后可通过 .postMessage() 通信，通过 .terminate() 立即销毁：
- 新建时传入脚本 URL，支持模块 Worker（
new Worker('worker.js', { type: 'module' })） - 监听
worker.onmessage或使用addEventListener('message', ...) - 调用
worker.terminate()后，Worker 立即停止执行，无法再通信 - 注意：
terminate()不会触发worker.onmessage或worker.onerror，也不等待当前任务完成
SharedWorker：多页面共享 + 关闭依赖页面卸载
SharedWorker 生命周期与「引用它的所有浏览上下文」绑定，主线程无法强制终止，只能断开连接：
- 创建方式为
const sw = new SharedWorker('shared.js')，所有同源页面可复用同一实例 - 通过
sw.port发送/接收消息，需先调用port.start()启用显式消息通道 - 页面卸载（如关闭标签页或导航离开）时自动调用
port.close()，当所有端口关闭后，浏览器通常在几秒内销毁 SharedWorker - Worker 内可通过监听
self.onconnect获取新连接，并在port.onclose中感知断连 —— 但无法主动 kill 自身
ServiceWorker：注册驱动 + 浏览器托管 + 事件钩子干预
ServiceWorker 不由页面直接实例化，其生命周期由浏览器基于注册、安装、激活、更新、失效等状态自动管理，开发者只能通过事件和 API 间接引导：
- 注册调用
navigator.serviceWorker.register('sw.js')，返回 Promise，成功后进入「等待中（waiting）」状态 - 安装阶段触发
install事件，可用event.waitUntil()延迟进入等待态（例如缓存资源） - 激活前若已有旧版激活中，新 SW 会停留在 waiting 状态；调用
skipWaiting()可跳过等待，立即激活 - 激活后触发
activate事件，常用于清理旧缓存；此时调用clients.claim()可让 SW 立即控制当前页面 - 卸载需调用
registration.unregister()，但浏览器可能延迟执行（如仍有 clients 使用该 SW），且无法保证立即终止运行中的事件监听器
跨 Worker 类型的通用管理建议
虽无统一 terminate 接口，但可通过封装+约定提升可维护性：
- 在 Worker 脚本中统一监听
'dispose'消息，收到后自行清理定时器、关闭 fetch 拦截、调用self.close()（对 Worker/SharedWorker 有效，SW 不支持） - 对 ServiceWorker，主线程可在
unregister()后发送 postMessage 触发其内部清理逻辑（需提前在 SW 中监听并处理） - 利用
navigator.serviceWorker.getRegistration()、window.navigator.serviceWorker.controller等检查状态，避免重复注册或误操作 - SharedWorker 和 ServiceWorker 都支持
onerror和onstatechange（后者仅 SW），可用于异常监控和状态追踪
不复杂但容易忽略：Worker 类型不同，「销毁」的语义完全不同——Worker 是立刻终结进程，SharedWorker 是释放引用，ServiceWorker 是发起卸载请求。理解这个差异，才能写出健壮的生命周期管理逻辑。
