宏任务是JavaScript事件循环中的核心调度单位，每轮事件循环都会从宏任务队列中取出一个任务执行，执行完毕后再清空微任务队列。要真正理解代码的执行顺序，光知道"微任务优先于宏任务"还不够，你得清楚到底哪些API会把回调塞进宏任务队列。很多人能脱口而出setTimeout，但被问到requestAnimationFrame算不算宏任务、Promise的回调算不算宏任务时就开始含糊了。这篇文章就把浏览器和Node.js两边会产生宏任务的API梳理清楚。
定时器类API：最经典的宏任务来源
setTimeout、setInterval和setImmediate这几个名字里带"定时"味道的函数，是最容易被识别的宏任务来源。setTimeout(callback, delay)会把回调包装成一个任务，在至少延迟delay毫秒后进入宏任务队列。注意这里说的是"至少"，因为主线程可能正忙于处理其他任务，定时器回调只能排队等待。
一个常被忽略的细节是：HTML规范规定setTimeout的最小延迟是4毫秒（嵌套超过5层时），所以即便你写setTimeout(fn, 0)，回调也不会立即执行，实际的延迟不会小于4ms。这也是为什么在循环里用setTimeout(fn, 0)做性能优化时，效果往往不如预期。看下面的例子：
console.log('start');
setTimeout(() => {
console.log('timeout 0ms');
}, 0);
Promise.resolve().then(() => {
console.log('promise');
});
console.log('end');
// 输出顺序：start -> end -> promise -> timeout 0ms输出结果验证了两件事：第一，setTimeout回调是宏任务，要等当前脚本（这本身也是一个宏任务）执行完、微任务清空后才有机会执行；第二，setTimeout(fn, 0)并非真正的零延迟。setInterval同理，它每隔指定时间向宏任务队列添加一个回调任务，但如果前一个回调还没执行完，后续任务不会叠加执行，而是被跳过或延迟，这一点在回调耗时较长时要格外小心。
在Node.js环境中还有一个setImmediate，它同样产生宏任务，并且在Node的事件循环中排在定时器阶段之前检查（check阶段）。虽然两者行为相似，但执行时机的判断逻辑不同，这一点后面会单独说。
DOM事件回调与用户交互：被低估的宏任务大户
所有通过addEventListener注册的事件回调，都是宏任务。点击按钮、键盘输入、鼠标移动、窗口resize，这些事件触发时，浏览器会把对应的回调作为独立的宏任务放入队列。这意味着事件回调里触发的微任务（比如Promise的then）会在当前回调结束后立刻执行，但要等下一个宏任务开始前，其他排队的点击事件才轮得上。
一个经典实验能说明问题：如果一个按钮的click事件回调里通过代码再触发一次click，浏览器是同步派发还是异步派发？答案是异步的——element.click()触发的事件派发同样作为宏任务排队。而在某些实现里，嵌套派发的事件会像同步任务一样插入执行，这也是不同浏览器之间曾经存在行为差异的地方。写UI交互代码时，如果你依赖事件的执行顺序，一定要意识到每个事件回调之间都可能夹杂着微任务的清理过程。
与DOM事件同属一类的还有MessageChannel和postMessage。MessageChannel的两个端口之间通信，接收方的onmessage回调就是宏任务。很多框架内部用它来实现"尽快但不阻塞"的调度，比如Vue的nextTick在微任务不可用时会回退到MessageChannel，React早期版本也用它做任务切片。看一个例子：
const channel = new MessageChannel();
channel.port1.onmessage = () => {
console.log('宏任务：message');
};
Promise.resolve().then(() => {
console.log('微任务：promise');
});
channel.port2.postMessage(null);
// 输出顺序：微任务：promise -> 宏任务：message这个特性让MessageChannel成为实现"比setTimeout(0)更快"的宏任务调度的首选方案，因为它没有4ms的最小延迟限制。除了MessageChannel，老式的window.postMessage也能达到类似效果，只是使用起来不如MessageChannel直观。
I/O、网络请求与渲染相关的宏任务
第三类宏任务来源是I/O操作。浏览器中的XMLHttpRequest和fetch，虽然fetch基于Promise，看起来像微任务体系的一部分，但网络请求本身的完成事件（数据到达、连接结束）是由浏览器的事件循环作为宏任务派发的，之后才解析Promise触发微任务。同理，FileReader读取文件的回调、indexedDB的请求完成回调、Web Worker通过onmessage回传消息，都属于宏任务范畴。
在Node.js中，I/O宏任务的种类更多：文件读写（fs模块）、网络套接字、DNS查询、子进程的输出，这些回调都进入事件循环的poll阶段等待执行。Node还提供了process.nextTick，注意它不是宏任务也不是微任务，而是一个优先级比微任务还高的特殊队列，经常有人把它和setImmediate搞混。对比一下：
const fs = require('fs');
fs.readFile(__filename, () => {
console.log('I/O回调：宏任务');
setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));
process.nextTick(() => console.log('nextTick'));
Promise.resolve().then(() => console.log('promise'));
});
// 输出顺序：nextTick -> promise -> immediate -> timeout在这个I/O回调内部，nextTick最先执行，然后是Promise微任务，接着setImmediate（check阶段）先于setTimeout（timers阶段）执行，这正是Node事件循环阶段顺序决定的。掌握这个顺序对排查异步时序问题非常有用。
最后单独说两个容易产生误解的API。其一是requestAnimationFrame：它的回调在渲染流程中执行，严格来说不属于标准的宏任务队列，而是跟随浏览器的渲染帧节奏，所以它的执行时机和setTimeout完全不同，常被归为独立的一类。其二是requestIdleCallback，它在浏览器空闲时执行，也可以算作一类特殊任务。它们和Promise的then回调有本质区别——后者是纯粹的微任务，绝不会进入宏任务队列。
总结一下，宏任务来源可以归为三大类：脚本执行本身、定时器类（setTimeout、setInterval、setImmediate）、事件与I/O类（DOM事件、MessageChannel、网络请求、Worker消息、Node的I/O回调）。而Promise、MutationObserver、queueMicrotask、process.nextTick这些都属于微任务或优先级更高的队列。写异步代码时，先判断回调属于哪一类，执行顺序基本就能推导出来了。
宏任务事件循环JavaScript异步修改时间：2026-09-04 14:08:41