事件循环的核心是调用栈清空后先执行完所有微任务，再执行一个宏任务；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 主线程只做两件事：发起调用 和 注册回调，中间不挂起线程。
立即学习“Java免费学习笔记（深入）”；
-
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 其实是语法糖，背后仍是微任务调度。
