17370845950

事件循环的核心是调用栈清空后先执行完所有微任务，再执行一个宏任务；setTimeout(fn, 0) 不立即执行，因属宏任务，需等同步代码和微任务完成后才运行。

事件循环的核心：调用栈、任务队列与微任务队列的协作

JavaScript 是单线程语言，靠事件循环（Event Loop）协调同步代码执行与异步回调调度。关键不是“多线程”，而是“分时交出控制权”——当 call stack 清空后，引擎主动从 microtask queue（如 Promise.then、queueMicrotask）取任务执行，直到队列为空；再检查 macrotask queue（如 setTimeout、setInterval、I/O 回调），取一个执行。

这个顺序决定了实际执行优先级：microtask 总是插在每次宏任务结束之后、下一个宏任务开始之前，且会清空整个微任务队列。

为什么 setTimeout(fn, 0) 不会立即执行

setTimeout 注册的是宏任务，即使延迟为 0，也要等当前调用栈清空 + 所有已排队微任务执行完，才轮到它。这是最常被误解的点。

• 当前同步代码（如 console.log('a')）一定先于 setTimeout(..., 0) 的回调
• 所有已存在的 Promise.then 回调会在该 setTimeout 回调之前执行
• 浏览器最小延迟约 4ms（setTimeout 实际不会低于此值），但 Node.js 中可接近 1ms

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

非阻塞异步操作的本质：不等结果，只注册回调

JavaScript 的异步能力不来自语言本身，而来自宿主环境（浏览器或 Node.js）提供的 Web API 或 libuv 接口。这些 API 在后台线程或系统调用中执行耗时操作（如网络请求、文件读取、定时器），JS 主线程只做两件事：发起调用 和 注册回调，中间不挂起线程。

• fetch() 立即返回一个 Promise，不等响应到达
• fs.readFile()（Node.js）触发系统 I/O 后立刻返回，不等待磁盘读完
• 回调函数被推入对应的任务队列（微任务或宏任务），由事件循环后续调度

真正的“非阻塞”，是 JS 引擎不参与耗时计算，把活交给底层，自己只管排队和分发。

容易踩坑的典型场景

实际开发中，错误常源于对任务队列层级的误判，尤其是混合使用 Promise、async/await 和 setTimeout 时。

• await 后的表达式一旦是 Promise，其 then 回调属于微任务；但 await 之后的代码会被编译成微任务链，不是同步执行
• process.nextTick()（Node.js）比 Promise.then 更早执行，但它不属于标准 Event Loop 规范，仅 Node 特有
• 在 requestAnimationFrame 回调里修改 DOM，再用 setTimeout 读取布局，可能读不到更新后的尺寸——因为 rAF 属于宏任务，但渲染发生在宏任务之后、下一轮事件循环之前，时机需用 queueMicrotask 或 getComputedStyle 配合判断

真正难的不是记住规则，而是意识到：你写的每行 JS 代码，都在某个明确的任务队列层级里排队，而“看起来像同步”的 await 其实是语法糖，背后仍是微任务调度。