JavaScript中不存在宏任务嵌套微任务导致的死锁，所谓“卡住”实为微任务无限递归引发的饥饿；应加退出条件、避免微任务轮询、警惕Promise链隐式递归，并用Performance面板和console.trace()调试。
JavaScript 中不存在“宏任务中嵌套微任务导致的死锁”，因为事件循环机制本身不支持也不允许死锁发生。所谓“死锁”，通常指多个任务互相等待、无限阻塞，而 JS 的单线程 + 事件循环模型天然规避了这种可能——它没有锁、没有抢占式调度、也没有线程间等待。你遇到的“卡住”“不执行”“看起来像死锁”的现象，其实是微任务无限递归或持续入队造成的饥饿（starvation），不是死锁。
下面直接说清楚怎么识别和处理这类问题：
宏任务里不断加微任务会怎样
当一个宏任务（比如 setTimeout 回调）里反复调用 Promise.resolve().then(...) 或 queueMicrotask()，且新微任务又继续添加新微任务，就会形成微任务风暴：
- 主线程永远在清空微任务队列，无法退出当前宏任务阶段；
- 后续宏任务（如另一个
setTimeout、用户点击、渲染）被无限推迟； - 页面表现为“假死”：按钮点不动、动画停摆、控制台无输出。
例如：
立即学习“Java免费学习笔记（深入）”；
setTimeout(() => {
console.log("start");
queueMicrotask(() => {
console.log("micro1");
queueMicrotask(() => {
console.log("micro2");
// 如果这里再加一个 queueMicrotask，且没终止条件……
// 就会一直跑下去
});
});
}, 0);这不会死锁，但若写成无限递归形式，就会耗尽调用栈或让页面无响应。
怎么避免微任务无限膨胀
- ✅ 加明确的退出条件：比如计数器、状态标记、数据边界判断
let count = 0; function run() { if (count >= 10) return; // 必须有出口 count++; queueMicrotask(run); } run(); - ✅ 不用微任务做轮询或重试逻辑：重试、轮询、节流等应放在宏任务中（如
setTimeout），否则容易失控 - ✅ 警惕 Promise 链中隐式递归：比如错误处理里又
.catch()并重新.then()，没设兜底就可能循环触发
真正卡死的常见误判场景
- ❌ 把
while (true)同步死循环当成“宏任务死锁” → 实际是主线程被占满，连事件循环都进不去 - ❌ 把
await在未 resolve 的 Promise 上当成“微任务卡住” → 实际是同步执行暂停，等待 Promise 状态变更，不占用微任务队列 - ❌ 把浏览器渲染冻结（如大量 DOM 操作未分片）当成“事件循环卡死” → 渲染被跳过，但微/宏任务仍在跑，只是你看不见 UI 变化
调试技巧
- 打开 Chrome DevTools → Performance 面板 → 录制一段操作 → 查看主线程是否长时间处于 “Microtask” 状态（黄色条持续高占比）
- 在可疑微任务开头加
console.trace()，看调用链是否异常深或重复 - 用
queueMicrotask(() => { debugger; })插入断点，观察是否反复触发
不复杂但容易忽略
