根本原因是微任务队列必须在当前宏任务结束前清空，若每次执行都动态创建新微任务，队列永不完结，主线程死锁，导致渲染、交互、定时器全部阻塞，页面假死。
直接禁止在微任务中动态创建新微任务——这是最根本的规避方式。微任务队列必须在当前宏任务结束前清空，若每次执行都新增一个微任务，队列永远无法变空，主线程被死锁，页面立即假死。
为什么无限微任务会卡死页面
事件循环规则明确：同步代码执行完 → 立即、全部、不间断执行完当前微任务队列 → 才取下一个宏任务。如果每个 Promise.then 都 new Promise 或调用 queueMicrotask，微任务就像滚雪球一样持续生成，主线程再无机会处理渲染、用户点击或定时器回调，浏览器判定为“脚本无响应”，几秒后可能弹出终止提示。
识别高风险写法
以下代码看似合理，实则危险：
- 递归式 Promise 链：Promise.resolve().then(() => { /* 处理逻辑 */; return Promise.resolve(); }).then(...)
- 监听+触发闭环：MutationObserver 回调中又修改了被观察的 DOM，触发新一轮回调
- queueMicrotask 嵌套调用：queueMicrotask(() => { /* 业务逻辑 */; queueMicrotask(() => {...}); })
安全替代方案
需要周期性或条件性执行逻辑时，改用宏任务调度，给事件循环留出喘息空间：
- 用 setTimeout(fn, 0) 替代连续微任务，确保每次只加入一个宏任务
- 对高频触发场景（如滚动、输入），加 节流（throttle） 或 防抖（debounce） 控制执行频次
- 耗时操作拆分：用 requestIdleCallback 在浏览器空闲时段分片执行，不抢占交互资源
- 真正需异步但不紧急的任务，移交 Web Worker 在后台线程运行，完全隔离主线程
调试与验证方法
打开 Chrome DevTools → Performance 面板 → 录制操作，重点关注 Main 线程是否持续 100% 占用、无渲染帧（Frames）输出；也可在代码中插入 console.time('micro') 和 console.timeEnd('micro') 快速定位长微任务。
