微任务队列本身不会无限循环，但代码写法不当会触发连续调度，导致事件循环卡在“清空微任务”阶段，无法推进渲染、用户响应或垃圾回收；危险模式包括无退出条件的Promise链、queueMicrotask嵌套调用、MutationObserver自触发闭环及高频事件中直接microtask更新。
微任务队列本身不会无限循环，但代码写法不当会触发连续调度，让事件循环卡在“清空微任务”阶段，无法推进到渲染、用户响应或垃圾回收——这看起来像死循环，实则是逻辑失控。
识别危险模式：哪些写法会悄悄锁死主线程
这些看似异步的写法，实际会阻断事件循环呼吸：
-
无退出条件的 Promise 链：比如
.then(() => { /* 业务逻辑 */; return Promise.resolve(); }).then(...)，每次 resolve 都触发下一个 then，队列永远不空 -
queueMicrotask 嵌套调用：如
queueMicrotask(() => queueMicrotask(() => {}))，新任务不断追加到队列尾部 - MutationObserver 自触发闭环：回调里修改了被观察的 DOM，又触发同一 observer 的新一轮回调
-
高频事件中直接 microtask 更新：滚动或输入时每帧都
queueMicrotask(render)，微任务数量随交互次数线性增长
关键防御策略：让微任务可终止、可释放、可降级
不是所有异步都该走微任务。优先级要分清，控制权要主动让出：
- 加明确退出标记：用布尔变量或状态比对控制是否继续调度，例如只在数据真正变更时才触发下一次更新
-
及时清理闭包引用：微任务函数内避免捕获大对象（如整个组件实例、未释放的 canvas 上下文），用完即设为
null - 改用 requestIdleCallback：适合非即时 UI 同步或批量处理，浏览器会在空闲时段执行，天然兼容渲染与 GC 窗口
-
重载操作移交宏任务：用
setTimeout(fn, 0)或postMessage触发，确保本轮微任务队列能清空，给事件循环喘息机会
兜底机制：现代引擎如何防止真卡死
你写的无限微任务链，V8、SpiderMonkey 等引擎不会坐视不管：
- 会对连续执行的微任务做计数，超过几百次后强制暂停，跳转到渲染或下一个宏任务
- 单个微任务若同步执行超时（如几十毫秒），也会被中断，防止长时间占用 CPU
- 这类保护不是规范强制，但已是各平台事实标准，目标是保页面可交互性
本质上，微任务不是“更快的 setTimeout”，而是“必须立刻做完的急事”。滥用它，等于把所有事情都标成加急，结果就是没人能喘气。合理划分任务边界，比优化单个回调更重要。
