HTML5 Web Worker 中 Worker 自身应调用 self.close() 主动退出，而非 close()；它确保已入队微任务执行完毕后终止线程，需配合主线程“请求-确认”模式实现优雅销毁。
HTML5 Web Worker 中没有 close() 方法供 Worker 自身调用以“自我销毁”——这是常见误解。Worker 线程的终止必须由主线程显式调用 worker.terminate()，而 Worker 内部只能通过 self.close() 主动退出自身线程（注意：不是 close()，而是 self.close()，且仅在 Worker 全局作用域中有效）。
Worker 内部如何正确调用 self.close() 实现优雅退出
self.close() 是 Worker 全局对象（self）提供的唯一标准方法，用于立即终止当前 Worker 线程。它不等待异步操作完成，但会确保已进入事件循环的任务（如已触发的 setTimeout 回调、已 resolve 的 Promise 微任务）执行完毕后才真正退出。
- 必须在 Worker 脚本中直接调用
self.close()，不能写成close()或window.close()（后者无效且报错） - 调用后，Worker 不再响应新消息，也不再触发定时器或 fetch 回调；但正在运行的同步代码和已入队的微任务仍会执行完
- 适合场景：任务完成、收到明确退出指令、长时间空闲超时、资源清理后主动退场
配合主线程实现双向协作式销毁
单靠 self.close() 不够“优雅”，因为主线程可能不知 Worker 已退出，也无法做后续清理。推荐“请求-确认”模式：
- Worker 收到主线程发来的
{ type: 'shutdown' }消息后，先执行清理（如取消 pending fetch、关闭 IndexedDB 连接、释放大数组引用） - 清理完成后，向主线程 postMessage({ type: 'shutdown_ack' })，再调用
self.close() - 主线程监听该 ack 消息，收到后可安全移除 worker 引用、清理 DOM 或状态
避免 self.close() 失效的常见陷阱
self.close() 在以下情况不会生效或引发异常：
立即学习“前端免费学习笔记（深入）”；
- 在非 Worker 环境（如普通 script 或模块顶层）中调用 —— 报
self.close is not a function - 在 Service Worker 中不可用（Service Worker 使用
self.skipWaiting()和生命周期控制，不支持 close） - 调用前已发生未捕获异常导致线程崩溃 —— 此时 close 不会被执行
- 在
importScripts()加载失败后的错误回调中调用 —— 可能因执行环境未就绪而静默失败
替代方案：用终止信号 + 定期检查实现软退出
若需更可控的退出流程（例如等待异步上传完成），可用标志位 + 循环检测代替立即 close：
- 主线程发送 { type: 'request_exit', timeout: 5000 }，Worker 将
shouldExit = true并启动计时器 - Worker 在关键异步操作（如 fetch）的 .finally() 中检查
shouldExit，满足条件则调用self.close() - 超时仍未退出，则无条件
self.close()，避免线程滞留
