事件循环与异步原理的核心机制
调用栈、任务队列与微任务队列的关系
在 JavaScript 的执行模型中，调用栈负责一次性执行当前待处理的脚本段，当栈空时才处理下一个等待的任务。与此同时，浏览器和运行时提供两类队列来调度异步工作：宏任务队列和 微任务队列。这两者的区别决定了异步代码的实际执行顺序。
在事件循环的每一轮中，先从调用栈取出并执行一个任务，然后处理所有的 微任务，再处理一个宏任务队列中的任务。这个顺序是理解 setTimeout 执行时机的关键点。
宏任务与微任务的执行时机与顺序
微任务通常包括 Promise.then、catch、finally 的回调，以及 MutationObserver 等，在当前宏任务结束后、下一轮事件循环开始前执行，确保微任务能尽快完成。这也是为什么 Promise 回调往往在 setTimeout 之前执行的原因。
宏任务的队列包括了来自 setTimeout、setInterval、I/O 操作等的回调。每一个宏任务完成后，事件循环会回头清空微任务队列，随后才从宏任务队列中取出下一个任务继续执行。
掌握 setTimeout 的执行时机
setTimeout 的基本行为与常见误区
虽然你可以设置一个等待时间 delay，但 回调的实际执行时间并非严格等于 delay，它受到当前任务队列的拥塞、虚拟时间与浏览器实现的影响。
常见误区是把 setTimeout 的 delay 看作“精准计时器”。事实上，delay 表示最小等待时间，当事件循环空闲后才会执行回调，这也解释了为何多次 setTimeout 可能会出现“堆叠”效果。
setTimeout 与宏任务、微任务的相互作用
每当一轮事件循环结束并清空微任务后，若宏任务队列中存在待执行的 setTimeout 回调，便会从队列中取出一个执行。若前一个宏任务中又调度了微任务，这些微任务将在当前轮次继续执行，直到微任务队列清空。
console.log('start');
setTimeout(() => { console.log('timeout 1'); }, 0);
Promise.resolve().then(() => { console.log('promise'); });
console.log('end');实战要点：提升异步执行与界面响应
在 UI 动画与用户操作中合理使用 setTimeout
为了保持界面平滑，常在高频事件（如滚动、触摸）中用 setTimeout 将耗时逻辑分解到下一轮事件循环，避免阻塞主线程。
另外，短的延迟可以让浏览器在渲染前完成布局和风格计算，从而提升可交互性。使用时应结合 requestAnimationFrame 做时序对齐会更合适。
结合 Promise 与 async/await 的执行顺序分析
在复杂的异步流程中，构造一个执行顺序图，可以帮助你判断 setTimeout、Promise 与 async/await 的相对执行时机。通常，Promise 的回调先于 setTimeout 执行，因为 Promise 属于微任务。
下面给出一个常见的组合示例，用于直观对比执行顺序，帮助排查“哪一步先执行”的疑问。
console.log('A');
setTimeout(() => console.log('B'), 0);
Promise.resolve().then(() => console.log('C'));
(async () => { console.log('D'); })();
console.log('E');常见场景分析：跨浏览器与 Node.js 的差异
浏览器与 Node.js 的事件循环差异
浏览器环境和 Node.js 的事件循环在实现细节上存在差异，但核心概念保持一致：微任务在宏任务结束后执行，且在下一轮事件循环开始前完成。
在 Node.js 中，process.nextTick 的行为近似微任务队列，但其优先级高于 Promise 的微任务，这影响了执行顺序。理解这一点对服务器端的异步控制尤为关键。
跨平台调试的实用技巧
要定位异步执行时序，可以通过在不同阶段打印日志，或使用浏览器开发者工具的“异步调用栈”来跟踪。需要关注的是事件循环轮次与微任务清空的时序，这会直接影响 UI 更新和网络请求的时序。
console.log('start');
setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('promise'));
console.log('end');