Event Loop 是浏览器渲染主线程的调度模型，非 JS 引擎独立实现；它串行执行宏任务、清空微任务、再触发渲染，依赖定时器、事件、网络等线程投递任务，确保单线程 JS 与流畅 UI 协同运行。
Event Loop 不是 JavaScript 引擎自己实现的独立机制，而是浏览器渲染进程在多线程协作下，为保障 JS 单线程执行与页面流畅渲染而设计的主线程调度模型。它本质上是渲染主线程的工作方式，依赖其他线程（GUI 渲染、事件触发、定时器、网络等）协同配合，共同服务于“不卡顿、可响应、能异步”的用户体验。
渲染主线程是 Event Loop 的唯一执行主体
所有 JS 代码（包括 script 整体、回调函数）、DOM 操作、样式计算、布局、绘制准备等，都在这个线程上串行执行。它持续运行一个“取任务 → 执行 → 再取任务”的无限循环：
- 每次循环只处理一个宏任务（如 setTimeout 回调、用户点击事件、script 初始化）
- 宏任务执行完后，立即清空当前所有微任务（如 Promise.then、MutationObserver 回调）
- 微任务全部执行完毕，才可能触发一次 GUI 渲染（即重排重绘）
- 然后继续下一轮宏任务——这就是 Event Loop 的基本节奏
GUI 渲染线程与 JS 引擎线程互斥，Event Loop 必须让出控制权才能渲染
JS 可修改 DOM/CSS，而 GUI 线程要依据最新状态绘制画面。二者不能同时运行，否则画面可能显示中间态或不一致数据。因此：
- 当 JS 主线程正在执行（比如一段长循环或复杂计算），GUI 渲染线程被挂起
- 此时即使有样式变更或动画帧请求，也会排队等待 JS 空闲
- Event Loop 在微任务清空后，会主动让出控制权，通知 GUI 线程“可以渲染了”
- 若 JS 执行太久（如 100ms 以上），用户就会感知卡顿——因为渲染被阻塞了
其他线程通过消息队列向主线程投递任务，驱动 Event Loop 运转
定时器线程、事件触发线程、网络线程等都不直接执行 JS，而是把就绪的任务（回调）按类型放入对应队列，由 Event Loop 调度：
立即学习“Java免费学习笔记（深入）”；
- setTimeout/setInterval 到期 → 定时器线程将回调推入宏任务队列
- 用户点击/键盘输入 → 事件触发线程将事件回调推入宏任务队列（通常在当前宏任务之后）
- fetch 请求完成 → 网络线程将 then 回调推入微任务队列
- MutationObserver 检测到 DOM 变更 → 触发线程将回调推入微任务队列
这些线程彼此独立，但都遵循统一规则：不抢主线程，只“投递”，不“执行”。Event Loop 就是那个始终在线、按序取件、不漏不错、永不宕机的快递分拣员。
Web Worker 是绕过 Event Loop 的“外包协作者”
当有密集计算（如图像处理、加密解密、大数据排序）时，主线程执行会严重拖慢 Event Loop 节奏。Web Worker 提供了一条解决路径：
- 它由浏览器启动独立线程，完全不共享主线程内存，也不能操作 DOM
- 主线程用 postMessage 发送数据，Worker 线程在后台计算，再用 postMessage 返回结果
- 整个过程不占用主线程时间，Event Loop 继续照常运转，页面保持响应
- Worker 相当于把“耗时任务”从 Event Loop 的调度范围中剥离出去，交给浏览器底层线程池托管
