web worker 生命周期管理关键在于创建即启动、终止需主动、错误要捕获；必须显式调用terminate()或self.close()，避免内存泄漏与静默崩溃，且三类worker终止机制各不相同。

Web Worker 的生命周期管理关键在于三点：创建即启动、终止需主动、错误要捕获。它不是自动运行完就消失的“一次性线程”，而是需要你明确控制起始与收尾，否则容易造成内存泄漏或静默崩溃。

创建 Worker：同源限制与模块支持

主线程通过 new Worker('path/to/worker.js') 实例化即启动线程。脚本必须与主页面同源（协议、域名、端口一致），否则抛出安全异常。支持 ES 模块语法，可传入 { type: 'module' } 选项：

• 普通脚本：const worker = new Worker('worker.js');
• 模块 Worker：const worker = new Worker('worker.mjs', { type: 'module' });
• Worker 内部无法访问 window、document 或任何 DOM API，只能使用 self 作为全局对象

终止 Worker：主线程 vs Worker 自身

Worker 不会随页面卸载自动销毁，必须显式终止。方式有两种，适用场景不同：

• 主线程调用 worker.terminate()：立即停止执行，不等待当前任务完成，也不触发 onmessage 或 onerror；适合紧急中止或资源回收
• Worker 内部调用 self.close()：优雅退出，适合任务自然结束时主动关闭；调用后该 Worker 不再响应新消息
• 注意：terminate() 后不能再通信，也不能重复使用该实例；如需再次运行，必须新建 Worker

错误处理：静默终止风险与监听策略

Worker 内未捕获的异常不会影响主线程，但会导致 Worker 静默终止——无报错、无提示、通信中断。必须建立双层防护：

• 主线程监听 worker.onerror：捕获初始化失败、脚本加载错误或跨域问题
• Worker 内部用 try/catch 包裹核心逻辑，并配合 self.onerror 捕获未处理异常，再通过 postMessage 主动上报错误信息
• 推荐做法：在主线程中结合 onerror 和 onmessage 判断状态，发现异常后及时 terminate() 并重建实例

不同类型 Worker 的终止差异

三种 Worker 的生命周期控制权归属不同，不能混用同一套终止逻辑：

• Dedicated Worker：完全由创建它的主线程控制，terminate() 立即生效
• Shared Worker：多个页面共享，主线程无法强制终止；只能调用 port.close() 断开连接，等所有端口关闭后浏览器自动销毁
• Service Worker：由浏览器托管，主线程只能通过 registration.unregister() 发起卸载请求，实际终止时间不可控，且可能仍有事件监听器在运行