JavaScript异步编程基于事件循环，宏任务（如setTimeout）在下一轮执行，微任务（如Promise.then）在本轮末尾清空；setTimeout(0)不立即执行因需等待同步代码和微任务完成，输出顺序为1 4 3 2。
JavaScript 异步编程不是“等它做完再往下走”，而是“告诉它干啥，然后继续干别的，等它干完再回头处理结果”。事件循环（Event Loop）就是那个盯着任务队列、决定什么时候执行回调的调度员——它不神秘，但错位理解会导致 setTimeout 不准、Promise 链行为反直觉、甚至 UI 卡死。
为什么 setTimeout(0) 不会立刻执行
因为 setTimeout 的回调被放进**宏任务队列（macrotask queue）**，而当前同步代码和微任务（如 Promise.then）必须先跑完。即使设为 0，它也要等本轮事件循环清空微任务后，才在下一轮开头执行。
常见错误现象：
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4);输出是
1 4 3 2，不是 1 4 2 3。
-
setTimeout、setInterval、I/O、UI 渲染属于宏任务，排队等下一轮 -
Promise.then/catch/finally、MutationObserver、queueMicrotask是微任务，插队到本轮末尾执行 - 浏览器中最小超时值实际约
4ms（非 0），Node.js 约1ms
Promise.then 为什么比 setTimeout 快
关键不在“快”，而在**执行时机不同**：Promise.then 回调进入微任务队列，setTimeout 进入宏任务队列。事件循环每轮只取一个宏任务，但会清空全部微任务。
实操建议：
Promise.resolve().then(() => console.log('a'));
Promise.resolve().then(() => console.log('b'));
setTimeout(() => console.log('c'), 0);输出一定是 a b c，哪怕 c 的定时器先注册。
- 连续多个
Promise.then会按顺序立即串行执行（本轮微任务队列内） - 想打断长链避免阻塞渲染？用
queueMicrotask或拆成setTimeout(..., 0)推到下一轮 - 不要依赖
Promise.then的“即时性”做时间敏感操作（比如动画帧同步）
async/await 本质是语法糖，不是线程切换
async 函数返回 Promise，await 只是暂停函数执行、把后续代码转成 Promise.then 回调——它不释放线程，也不让出 CPU，只是让 JS 引擎把控制权交还给事件循环。
立即学习“Java免费学习笔记（深入）”；
容易踩的坑：
async function f() {
console.log('start');
await Promise.resolve();
console.log('end');
}
f();
console.log('after');输出是 start after end，不是 start end after。
-
await后面如果不是Promise，会被自动包装成Promise.resolve(value) -
await不会阻塞整个调用栈，只暂停当前async函数内部执行流 - 密集计算（如大数组遍历）加
await并不能防卡顿，得配合setTimeout或requestIdleCallback
事件循环的复杂点不在概念本身，而在于宏任务与微任务的嵌套层级、浏览器与 Node.js 的实现差异（比如 Node.js 的 process.nextTick 比微任务还优先）、以及 DOM 更新时机（render 阶段夹在宏任务之间）。写异步逻辑时，少猜执行顺序，多用 console.timeLog 或 DevTools 的 Event Log 面板看真实调度。
