事件循环是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
微任务和宏任务有哪些典型来源？
区分不清任务类型，是调试异步逻辑混乱的最常见原因。关键不是记名字，而是理解它们在事件循环中的插入点和优先级。
立即学习“Java免费学习笔记（深入）”；
-
宏任务：每次事件循环只执行一个，包括
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 显式控制时机。
