EventLoop中微任务优先于宏任务执行，且每个宏任务后必须清空全部微任务；宏任务决定循环节奏，微任务构成原子性执行块。
浏览器中 EventLoop 区分微任务队列和宏任务队列，关键不在于“谁先注册”，而在于执行时机、优先级规则和任务来源的硬性约定。两者不是并列排队的两个队伍，而是有严格嵌套关系的调度层级。
宏任务队列：定义事件循环的主节奏
宏任务是事件循环每次循环的“起点”和“单位”。浏览器每次只从宏任务队列中取出一个任务执行，执行完才进入下一阶段。这个“一帧一任务”的节奏由浏览器内核控制。
- 常见宏任务：全局 script 代码块、
setTimeout/setInterval回调、DOM 事件（如click、input）、requestAnimationFrame回调、UI 渲染（浏览器自动插入，不可手动添加） - 注意：
<script>标签本身就是一个宏任务——多个 script 标签会依次作为独立宏任务入队 - 宏任务之间可能插入 UI 渲染，这是浏览器保障界面响应性的关键时机
微任务队列：紧贴宏任务尾部的强制清空区
微任务没有“轮次”概念，它不参与节奏分配，只在每个宏任务执行完毕后、下一个宏任务开始前，被一次性全部执行完。哪怕中途新增微任务，也会被纳入本轮清空范围。
- 常见微任务：
Promise.then/.catch/.finally回调、async/await中 await 后的代码段、queueMicrotask()手动插入、MutationObserver回调 - 重要细节：Promise 构造函数内的执行器函数（executor）是同步的；只有
.then等方法注册的回调才是微任务 - 微任务之间绝不中断、不交出控制权——它们构成一个原子性执行块
区分的核心判断依据
不用死记列表，靠三条逻辑快速定位：
立即学习“Java免费学习笔记（深入）”；
- 是否必须等外部条件就绪？ 宏任务通常依赖外部时机（如定时器到期、用户点击、I/O 完成），不确定性高；微任务则基于内部状态已确定的操作（如 Promise 已 resolve，只需通知回调），确定性强、耗时短
-
是否在当前 JS 执行流结束后立刻跑？ 是 → 微任务；否 → 宏任务（哪怕延时为 0 的
setTimeout也得等下一轮宏任务） -
是否影响渲染时机？ 宏任务之间可触发渲染；微任务全部执行完才可能渲染——所以高频微任务（如滥用
Promise.then）会阻塞页面更新
一个典型执行序列（帮助建立直觉）
以这段代码为例：
console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
输出顺序是 1 → 4 → 3 → 2。原因：
- 同步代码
1和4立即执行 - 宏任务
setTimeout进入宏任务队列，等待下一轮 - 微任务
Promise.then进入微任务队列，同步代码一结束就立即执行 - 当前宏任务（整个 script）执行完 → 清空微任务队列（输出
3）→ 渲染（可选）→ 取下一个宏任务（setTimeout，输出2）
