宏任务在事件循环中排队于宏任务队列，需等当前同步代码执行完且微任务队列清空后，才由Event Loop按先进先出顺序取出一个执行。
宏任务到底在哪个环节排队
宏任务不是一创建就立刻执行，而是在当前调用栈清空后、由事件循环（Event Loop）从宏任务队列（macrotask queue）里按先进先出顺序取出一个执行。关键点在于：setTimeout、setInterval、setImmediate（Node.js）、I/O 回调、UI 渲染（浏览器）这些都属于宏任务源，但它们的回调函数本身不会“插队”进当前同步代码——哪怕你写 setTimeout(fn, 0)，fn 也得等完所有同步代码 + 当前微任务队列清空后才轮到。
为什么 setTimeout(0) 不等于立刻执行
因为 0 只是告诉宿主环境“尽快安排”，实际调度权在 Event Loop。常见误解是把它当“异步立即执行”，结果写出依赖时序的 bug。比如：
console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
输出一定是 1 → 4 → 3 → 2。原因：Promise.then 是微任务，优先于宏任务执行；setTimeout 的回调被推入宏任务队列，要等本轮循环的微任务全部跑完才取。
-
setTimeout的延迟参数最小有效值受浏览器限制（通常 ≥4ms），Node.js 约为 1ms - 连续多次
setTimeout(fn, 0)会生成多个独立宏任务，按插入顺序排队，不是合并或去重 - 若主线程长时间阻塞（如 while(true)），宏任务队列会积压，
setTimeout实际触发时间远超设定值
宏任务与微任务嵌套时的执行边界
每次宏任务执行完毕，Event Loop 就会清空整个微任务队列（不是只执行一个），然后才取下一个宏任务。这意味着：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 在
setTimeout回调里Promise.resolve().then(...)，该then会加入本轮微任务队列末尾，仍属于“当前宏任务结束后立即执行”的范畴 - 但在该
then里再调用setTimeout，新宏任务会排到“下一轮”宏任务队列尾部，绝不会插在当前微任务中间 - Node.js 中
process.nextTick()比 Promise 微任务更早执行，但它仍是微任务层级，不影响宏任务排队逻辑
调试宏任务排队状态的实用方法
浏览器 DevTools 无法直接查看宏任务队列内容，但可通过组合手段观察行为：
- 用
performance.now()打点对比宏任务实际触发时间与预期时间差，判断是否被阻塞 - 在
setTimeout回调开头加console.log('tick:', performance.now())，配合同步日志定位调度延迟 - 避免用
debugger断点打断宏任务流程——断点会暂停整个 JS 执行，导致后续宏任务无法推进，看到的不是真实调度顺序 - Node.js 可用
--trace-events-enabled --trace-event-categories v8,devtools.timeline生成 trace 文件，在 chrome://tracing 中查看宏任务调度时序
真正容易被忽略的是：宏任务队列没有“优先级”概念，所有来源（定时器、网络响应、用户输入）都扁平排队；而微任务队列每次只服务一个宏任务，清空即止。这个“一次清空、下次再等”的边界，才是理解异步控制流的关键支点。
