事件循环是JavaScript内建的持续运行执行模型，每次迭代处理一个宏任务，随后清空全部微任务队列；setTimeout(fn,0)并非立刻执行，而是推入宏任务队列待下一轮循环。
JavaScript 的事件循环不是某种可以“开启”或“关闭”的开关，它是一套内建的、持续运行的执行模型，用来协调同步代码、宏任务（macro task）和微任务（micro task）的执行顺序。你不需要手动触发它，但必须理解它在什么时候执行什么，否则 setTimeout、Promise.then、async/await 的行为会显得“反直觉”。
宏任务和微任务的执行顺序怎么排？
每次事件循环迭代只处理一个宏任务（如 script 初始化、setTimeout 回调、setInterval 回调、I/O 回调），但会在该宏任务结束后、下一个宏任务开始前，**清空整个微任务队列**——也就是说，所有当前已就绪的 Promise.then、queueMicrotask、MutationObserver 回调都会被连续执行，中间不穿插任何宏任务。
常见错误现象：以为 setTimeout(() => console.log(2), 0) 一定在 Promise.resolve().then(() => console.log(1)) 之后打印，实际是先 1 后 2。
- 宏任务队列示例：
setTimeout、setImmediate（Node.js）、UI 渲染、postMessage - 微任务队列示例：
Promise.then/catch/finally、queueMicrotask、Object.observe（已废弃）、MutationObserver回调 - 注意：
async/await内部的await表达式后代码会被编译为Promise.then，所以属于微任务
setTimeout(fn, 0) 真的是“立刻执行”吗？
不是。它只是把 fn 推入宏任务队列，等待**当前调用栈清空 + 所有微任务执行完毕 + 下一轮事件循环开始时**才执行。浏览器还可能对极小延迟（如 0 或 1ms）做最小化限制（通常 ≥ 4ms），尤其在页面非活跃标签页中可能被进一步节流到 1000ms。
立即学习“Java免费学习笔记（深入）”；
使用场景：需要“让出主线程”，避免阻塞渲染或响应用户输入，比如把大量计算拆成小块：
function processLargeArray(arr, i = 0) {
if (i >= arr.length) return;
// 处理单个元素
doSomething(arr[i]);
// 让出控制权，等下一帧再继续
setTimeout(() => processLargeArray(arr, i + 1), 0);
}
性能影响：滥用 setTimeout(..., 0) 会产生大量宏任务，增加调度开销；相比而言，queueMicrotask 更轻量，适合需紧随当前操作之后执行的逻辑。
为什么 Promise 构造函数里的代码是同步执行的？
因为 new Promise(executor) 中传入的 executor 函数会**立即同步调用**，而它的参数 resolve 和 reject 是由 JS 引擎注入的函数，调用它们只是将后续回调推入微任务队列，并不立即执行回调本身。
容易踩的坑：
- 误以为
new Promise(resolve => { console.log('A'); resolve(); console.log('B'); }).then(() => console.log('C'))输出是 A → C → B，实际是 A → B → C（resolve()不中断同步流程） - 在
executor中抛出未捕获错误，会直接变成 rejected Promise，等同于Promise.reject(e) - Node.js 中未处理的 rejected Promise 会触发
unhandledRejection事件，浏览器中可能仅报 warning
真正容易被忽略的点：事件循环本身没有“暂停”或“等待”能力；所谓“等待异步完成”，其实是把后续逻辑注册为回调，交由事件循环在合适时机调用。任何试图靠轮询或死等（如 while 循环检测某个 flag）来“同步等待”异步结果的做法，都会卡死主线程，让整个事件循环停滞。
