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()发起卸载请求，实际终止时间不可控，且可能仍有事件监听器在运行
