微任务无限循环会导致页面假死、CPU 占用100%、交互停滞但DevTools可能仍可用；需通过计数限制、Performance面板分析、临时改用setTimeout等方法定位并阻断，避免闭包自引用、MutationObserver误触发等陷阱。
微任务无限循环会让页面完全卡死，连开发者工具都可能打不开，关键要从源头阻断循环并快速定位问题点。
识别微任务无限循环的典型特征
页面假死但 CPU 占用持续 100%，控制台无报错、无法点击、定时器（setTimeout）不触发，但 Promise.then 或 queueMicrotask 的回调却在疯狂执行——这是最典型的信号。和宏任务卡死不同，它不会阻塞 DevTools 的 UI 线程（有时还能打开控制台），但所有微任务会不断抢占执行权，导致渲染和用户交互彻底停滞。
快速定位触发源的实操方法
在疑似代码区域插入防御性日志 + 执行计数限制：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 给每个
Promise.then、queueMicrotask或MutationObserver回调加一个全局计数器，比如let microCount = 0，每次进入就if (++microCount > 100) { debugger; } - 在 Chrome DevTools 的 Performance 面板录制时，勾选 “Screenshots” 和 “Event Log”，回放时重点看
PromiseResolve、Microtask是否密集连续出现（间隔常低于 0.1ms） - 临时禁用可疑代码段：把
Promise.resolve().then(...)改成setTimeout(..., 0)，如果页面恢复响应，基本可锁定是该链路引发的微任务风暴
常见陷阱与修复建议
以下写法极易引发隐式无限微任务循环：
立即学习“Java免费学习笔记（深入）”；
-
错误示例：
const p = Promise.resolve(); p.then(() => p.then(callback))—— 每次都返回同一个已 resolve 的 Promise，造成同步递归入队 -
错误示例：在
MutationObserver回调中直接修改被观察的 DOM 节点，又没做防抖或变化过滤，导致变更 → 触发 observer → 再次变更 → …… -
安全做法：用
setTimeout或requestIdleCallback替代高频微任务调度；对 observer 做节流（如用Set缓存 pending 变更，queueMicrotask统一处理后清空）；Promise 链中避免闭包引用自身或上游 promise
预防性调试技巧
开发阶段就降低风险：
- 全局拦截微任务入口（仅调试用）：
const originalQueue = queueMicrotask;<br> queueMicrotask = function(fn) {<br> if (window._microTaskCount === undefined) window._microTaskCount = 0;<br> if (++window._microTaskCount > 500) throw new Error('Too many microtasks');<br> return originalQueue(fn);<br> }; - 使用 ESLint 插件
eslint-plugin-promise启用avoid-new-promise-in-microtask等规则，提前发现危险模式 - 复杂状态更新逻辑优先走
requestAnimationFrame+ 宏任务组合，而非层层.then
