微任务队列不会无限执行，浏览器和运行时有保护机制：v8等引擎会对连续微任务计数或耗时限制，超阈值则暂停执行、让出控制权以保障渲染与交互；开发者应避免无终止条件的微任务链，优先使用宏任务或切片调度。
微任务队列不会“一直不空”而无限执行——浏览器或运行时环境有明确的保护机制，防止它饿死渲染、阻塞用户交互或导致页面无响应。
微任务是递归清空，但不是无限循环
每次宏任务结束后，事件循环会持续取出并执行微任务队列头部的任务，直到队列为空。关键在于：每执行一个微任务，如果它内部又调用 Promise.then、queueMicrotask 或 MutationObserver，新微任务会被追加到队列尾部，然后继续执行——这叫“递归清空”，但它仍受限于单次宏任务上下文。
也就是说，只要微任务自身不主动触发新的微任务，队列终将耗尽；但如果代码写成：
queueMicrotask(() => queueMicrotask(...))- 或在
then中无条件再链一个then
就会形成无限微任务链——此时引擎会干预。
实际运行时的兜底保护
现代浏览器（Chrome、Firefox、Safari）和 Node.js 都实现了微任务执行深度/耗时限制：
- V8 引擎会对连续执行的微任务做计数，超过阈值（如几百次）后暂停微任务执行，强制让出控制权，进入渲染或下一个宏任务
- 若某微任务执行时间过长（例如同步计算耗时几十毫秒），也会被中断，避免主线程卡死
- 这种保护不是规范强制要求，但已是事实标准，目的是保障页面可交互性
开发者该怎么做？
避免人为制造“永不停止”的微任务链，这是最根本的解法：
- 慎用无终止条件的
queueMicrotask自调用（比如进度更新没设上限） - 大量异步逻辑优先走宏任务（如
setTimeout(fn, 0)），尤其涉及 DOM 更新、动画帧或用户反馈时 - 必要时用
requestIdleCallback或requestAnimationFrame替代密集微任务，把工作切片并交还控制权
和宏任务相比，微任务更“急”，但不更“强”
微任务优先级高，只说明它会在当前宏任务后立刻执行；但它没有更高权限，也不能绕过浏览器的健康检查。一旦检测到异常持续占用主线程，运行时会降级处理——比如把后续微任务推迟到下一个事件循环周期，或直接抛出警告（DevTools 控制台可能提示 “Potential infinite microtask loop”）。
