Web Worker 拥有独立且完整的事件循环，含宏任务队列、微任务队列，与主线程隔离互不干扰；无需手动维护，但不可用 DOM 相关 API，通信依赖 postMessage/onmessage。
Web Worker 中没有“独立的事件循环”这个说法——它确实拥有自己的执行上下文和任务队列，但其事件循环机制与主线程本质相同，只是完全隔离、互不干扰。关键在于：Worker 是浏览器内核为其分配的独立线程（或类线程环境），自带一套完整的事件循环（含宏任务队列、微任务队列、渲染无关的执行模型），无需你手动“维护”。
Worker 自带完整事件循环，无需手动维护
当你调用 new Worker('script.js')，浏览器会为该 Worker 创建：
- 独立的 JavaScript 执行引擎实例（V8 实例）
- 独立的调用栈、堆内存、全局对象（
self代替window） - 独立的事件循环：包含自己的宏任务队列（如
setTimeout、postMessage回调）、微任务队列（Promise.then、MutationObserver）
这意味着你在 Worker 内写 setTimeout(() => console.log('tick'), 100) 或 Promise.resolve().then(() => console.log('micro'))，行为和主线程一致，且不会影响主线程的事件循环。
Worker 中不能使用 DOM 和部分主线程 API
因为事件循环运行在无 UI 的线程中，以下操作不可用（调用会直接报错）：
立即学习“Java免费学习笔记（深入）”；
-
document、window、localStorage、fetch（注意：现代 Worker 支持fetch，但需确认浏览器兼容性） -
requestAnimationFrame、EventTarget.addEventListener（除self上的事件如message、error） -
console.log可用（输出到 DevTools 的 “Console” 或 “Workers” 标签页）
Worker 的事件源仅限于：message（来自主线程或其他 Worker）、error、定时器、Promise、IndexedDB 请求完成、fetch 响应等异步完成回调。
跨线程通信靠 postMessage + onmessage
这是唯一安全、异步、基于事件循环的通信方式：
- 主线程调用
worker.postMessage(data)→ 数据被序列化（结构化克隆）并推入 Worker 的宏任务队列 - Worker 中的
self.onmessage = e => { ... }或self.addEventListener('message', ...)在下一个事件循环周期执行 - 同理，Worker 也可用
self.postMessage()向主线程发消息
⚠️ 注意：传递对象时不要传函数、DOM 节点、undefined；若需传大量数据，用 Transferable（如 ArrayBuffer）避免拷贝开销。
高级场景：Service Worker 和 Module Worker 的差异
普通 Web Worker 是最典型的“独立事件循环”实例。另外两种相关类型也值得区分：
-
Module Worker：
new Worker('worker.js', { type: 'module' })—— 支持 ES 模块导入，事件循环模型不变，只是模块解析逻辑不同 -
Service Worker —— 也是独立事件循环，但生命周期由浏览器控制（可被终止/唤醒），事件驱动（
install、fetch、push等），不支持setTimeout长期保持活跃（需用extendableEvent.waitUntil()）
它们都遵循同一套事件循环规范（HTML Standard 中定义的 WorkerGlobalScope 循环），只是触发事件的来源不同。
不复杂但容易忽略：所谓“维护”，其实是确保 Worker 代码只做纯计算或 I/O 密集型工作，避免阻塞自身事件循环（比如死循环），并合理使用 postMessage 协作，而非试图去“接管”或“模拟”事件循环。
