事件循环的任务切换是执行权在调用栈、微任务队列、宏任务队列间的移交，需调用栈清空才触发；微任务一次性全部执行，宏任务切换伴随渲染开销，async/await等语法糖带来上下文保存与恢复的隐式成本。
事件循环中的“任务切换”不是函数调用跳转，而是执行权在同步代码（调用栈）、微任务队列、宏任务队列之间移交的过程。这个过程本身开销极低，但频繁或不当的切换会放大实际成本——比如引发多余渲染、阻塞用户交互、或触发不必要的上下文重建。
调用栈清空是切换的前提
JavaScript 引擎只在调用栈完全为空时，才启动下一轮任务调度。这意味着：
- 所有同步代码必须执行完毕，包括深层嵌套的函数、循环和 try-catch 块
- 哪怕只剩一个 console.log() 没执行完，微任务也不会开始
- 长时间运行的同步逻辑（如万级 for 循环）会延迟微任务执行，造成 Promise.then “卡顿”假象
微任务队列清空是一次性动作
一旦调用栈空了，引擎会连续执行完当前所有微任务，中间不插入任何渲染或宏任务。这带来两个关键影响：
- Promise 链式调用（.then().then().then()）会在一次微任务轮次中全部跑完，不会被中断
- 如果某个 .then 回调里又创建了新 Promise，它的 .then 也会被加入本轮微任务队列末尾，继续执行
- 滥用 queueMicrotask 或嵌套 Promise 可能导致微任务“雪崩”，占用主线程过久，间接引发掉帧
宏任务切换伴随真实环境开销
从一个宏任务切换到下一个（例如 setTimeout → 下一个 setTimeout），中间必然经过渲染阶段和可能的浏览器空闲处理。这意味着：
- DOM 修改会在微任务清空后立即触发重排/重绘，这是可观察的性能开销
- UI 渲染完成后，浏览器才从宏任务队列取下一个任务——这个“取”的动作本身几乎无成本，但等待时间不可控（如用户正在滚动，可能被节流）
- setInterval 的回调若执行超时，后续调用会被挤压，形成“批量执行”，加剧主线程压力
异步操作带来的隐式切换成本
像 async/await 这类语法糖，底层仍依赖 Promise 和微任务。每次 await 后恢复执行，本质是：保存当前函数上下文 → 推入微任务队列 → 等待下一轮调度 → 恢复上下文。这个过程虽快，但有真实代价：
- 函数帧需序列化部分状态（如变量绑定、暂停点），尤其在闭包复杂时内存开销上升
- 大量细碎的 await（如循环内逐个 await fetch）会把一个逻辑拆成多个微任务，打断 CPU 局部性，降低缓存命中率
- 与同步代码相比，await 的恢复执行比普通函数调用多出约 2–5 倍的指令周期（实测 V8 10.x+）
