事件循环是JS运行时协调同步代码、异步回调与UI渲染的底层调度机制；宏任务（如setTimeout）每轮执行一个，微任务（如Promise.then）在每个宏任务后全部清空，故setTimeout(…,0)总比Promise.then晚执行。

JavaScript 事件循环不是某种 API 或函数，而是运行时（浏览器或 Node.js）协调同步代码、异步回调与 UI 渲染的底层调度机制。它让单线程的 JS 能“不卡页面”地处理定时器、网络请求、点击事件等异步任务。

为什么 setTimeout(…, 0) 总比 Promise.then 晚执行？

因为事件循环强制规定：每个宏任务结束后，必须先清空全部微任务队列，再取下一个宏任务。而 setTimeout 回调属于宏任务，Promise.then 属于微任务。

常见错误现象：以为“延时为 0 就等于立刻执行”，结果发现 DOM 更新延迟了一帧；其实不是 setTimeout 慢，是它被排在了微任务之后。

• console.log('1') 和 console.log('4') 是同步代码，立刻输出
• Promise.resolve().then(() => console.log('3')) 进入微任务队列
• setTimeout(() => console.log('2'), 0) 进入宏任务队列
• 同步执行完 → 执行所有微任务（'3'）→ 取一个宏任务执行（'2'）

console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
// 输出：1 → 4 → 3 → 2

微任务和宏任务有哪些典型来源？

区分不清任务类型，是调试异步逻辑混乱的最常见原因。关键不是记名字，而是理解它们在事件循环中的插入点和优先级。

• 宏任务：每次事件循环只执行一个，包括 setTimeout、setInterval、I/O（Node）、UI 渲染（浏览器隐式触发）、postMessage
• 微任务：每次宏任务后立即全部执行，包括 Promise.then/catch/finally、queueMicrotask()、MutationObserver（浏览器中监听 DOM 变化）
• process.nextTick（仅 Node.js）比所有微任务还早，但不属于标准事件循环规范

为什么在 Promise.then 里改 DOM，用户能“立刻看到”，而 setTimeout 里不行？

浏览器在每次微任务队列清空后、下一个宏任务开始前，会主动检查是否需要渲染——这个时机叫“渲染帧点”。所以微任务里的 DOM 修改会紧挨着渲染发生；宏任务则要等到下一轮事件循环，可能延迟 16ms（一帧）甚至更久。

使用场景：需要保证视觉反馈及时（如按钮点击态、加载状态切换），应优先用 Promise.resolve().then 或 queueMicrotask 包裹 DOM 操作，而非 setTimeout(..., 0)。

• 性能影响：滥用 setTimeout(..., 0) 会把本可即时更新的 UI 推迟到下一帧，造成肉眼可感的卡顿
• 兼容性：queueMicrotask 在现代浏览器中已稳定支持（Chrome 67+/Firefox 69+/Safari 15.4+），比反复 new Promise 更轻量

真正难的不是记住规则，而是意识到：你写的每一行异步代码，都在悄悄排队——队列里有优先级，有隐式渲染点，还有跨环境差异（比如 Node.js 没有 UI 渲染）。别依赖“看起来顺序对”，要用 queueMicrotask 或 Promise 显式控制时机。