宏任务持续入队但不执行，微任务原子性执行并追加新微任务。如代码输出1→6→3→5→2→4，宏任务B入队但排在A后，浏览器优化不破坏主干逻辑。
不会停止入队。微任务执行期间，宏任务照常排队，只是暂时不被取出执行。
宏任务持续入队，但事件循环不取新宏任务
只要代码在运行（比如定时器到时、网络响应返回、用户点击发生），宏任务就会按规则进入宏任务队列——这个过程完全不受当前是否在执行微任务影响。浏览器或 Node.js 的异步模块会独立检测条件并推入任务。但事件循环的调度逻辑是：当前宏任务结束后，必须先清空全部微任务，才允许取下一个宏任务。所以宏任务“进得来”，但“轮不到执行”。
微任务执行是原子性的，中间不穿插宏任务
一旦开始执行微任务队列，事件循环就锁定了本轮的执行范围：
- 所有已存在的微任务按顺序逐个执行
- 执行过程中产生的新微任务（比如
Promise.then里再链一个then）会追加到当前微任务队列末尾，并继续执行 - 哪怕此时
setTimeout触发了、click事件发生了、fetch响应回来了，对应回调都进了宏任务队列，也得等当前微任务队列彻底变空后，才会被取出
实际例子说明排队与执行分离
看这段代码：
console.log('1'); // 同步
setTimeout(() => console.log('2'), 0); // 宏任务A，立刻入队
Promise.resolve().then(() => {
console.log('3');
setTimeout(() => console.log('4'), 0); // 宏任务B，此时入队
Promise.resolve().then(() => console.log('5')); // 微任务C，追加进当前微任务队列
});
console.log('6');
输出顺序是 1 → 6 → 3 → 5 → 2 → 4。注意：setTimeout 回调 '4' 是在微任务中触发的，它确实入队了，但要等到 '2' 执行完（即宏任务A执行完）、渲染发生、再开启下一轮事件循环，才轮到它执行。宏任务B没有被丢弃，只是排在了宏任务A之后。
浏览器还会动态干预，但不破坏基本节奏
虽然宏任务持续入队，浏览器为保障响应性，可能对高优输入（如键盘、指针移动）做优先调度，甚至提前取出其对应的宏任务。但这属于运行时优化，不改变“微任务清空→渲染→取宏任务”的主干逻辑。长时间运行的微任务也可能触发浏览器警告，但不会中断队列机制本身。
