当前位置：首页 > 文章列表 > 文章 > 前端 > HTML事件循环怎么实现？Event Loop原理详解

HTML事件循环怎么实现？Event Loop原理详解

2026-05-18 09:18:49 0浏览收藏

为什么 setTimeout 和 Promise.then 执行顺序不一样

这不是 bug，是事件循环设计的必然结果：任务（Task）和微任务（Microtask）分属不同队列，且微任务在每次 Task 执行完后立即清空，不跨轮次。

setTimeout 回调进入「任务队列」（Task Queue），比如 timer queue，属于一个独立的任务源
Promise.then 回调进入「微任务队列」（Microtask Queue），它不属于任何 Task Queue，规范明确说 The microtask queue is not a task queue
执行栈清空后，引擎先检查并**一次性执行完所有当前微任务**，再取下一个任务 —— 这就是为什么连续两个 Promise.then 总比 setTimeout 先跑
注意：多个 setTimeout(fn, 0) 不会合并，它们各自排队，可能被其他高优先级任务（如用户点击）插队

用 requestIdleCallback 做低优先级后台任务

当你要执行非紧急逻辑（如日志上报、非关键状态同步），又不想卡住交互，requestIdleCallback 比 setTimeout(..., 0) 更合适 —— 它把任务交给浏览器，在主线程空闲且帧时间允许时才执行。

它不是微任务，也不是常规任务，而是由浏览器调度的「空闲时段任务」，优先级低于用户输入和动画帧
必须传入回调函数，且最好检查 deadline.timeRemaining() > 0，避免超时阻塞下一帧
不支持 Safari（截至 2026 年 5 月），需降级为 setTimeout 或 queueMicrotask（后者更轻量但无空闲感知）

示例：

requestIdleCallback(() => {
  console.log('此时主线程大概率没活干');
}, { timeout: 2000 });

Web Worker 里也有 Event Loop 吗

有，但它是**独立的** —— 每个 Worker 拥有自己的 V8 实例、自己的调用栈、自己的任务队列和微任务队列。主线程和 Worker 之间只能通过 postMessage 异步通信，不能共享内存或直接调用函数。

Worker 中的 setTimeout、fetch、Promise 都走它自己的 Event Loop，完全不影响主线程渲染
但 requestIdleCallback 在 Worker 中不可用（没有渲染上下文）
Worker 无法访问 document、window、localStorage 等 DOM 相关 API，这是有意为之的隔离设计
若你在 Worker 里写了个死循环（while(true) {}），它会彻底卡死该 Worker 的 Event Loop，但主线程照常响应

真正容易被忽略的点是：任务队列不止一个。点击事件、定时器、网络响应、DOM 变化监听（MutationObserver）都可能落在不同任务源（task source）对应的队列中，浏览器有权按需调度优先级 —— 所以别假设 setTimeout 一定比 fetch 回调先执行，也不该依赖多个 setTimeout 的绝对顺序。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~