JavaScript中不存在异步死循环，但错误await递归会持续堆积Promise链、事件循环任务和闭包引用，导致内存溢出（OOM）而卡死；安全做法是用setTimeout或queueMicrotask让出控制权，或改用分批迭代处理。
JavaScript 中不会出现传统意义上的“异步死循环”，但错误的 await 递归（尤其是无终止条件或未正确调度的递归调用）会导致**持续堆积 Promise 链、事件循环任务和闭包引用**，最终引发内存溢出（OOM），表现类似“卡死”或浏览器崩溃。
错误 await 递归如何形成隐式无限链
关键问题在于：每次 await 一个尚未 resolve 的 Promise，都会让当前函数暂停，并把后续逻辑推入微任务队列；若递归调用本身又立即创建新 Promise 并 await，就会在微任务队列中不断追加新任务，而旧任务尚未退出执行上下文——闭包持续持有着上层作用域变量（如数组、对象、计数器等），内存无法回收。
典型错误模式：
async function badRecursion(n) {
if (n <= 0) return;
// ❌ 错误：没有延迟、没有取消、没有限流，直接递归调用
await badRecursion(n - 1); // 每次都新建 Promise 并 await，但调用栈未释放
}表面看有递归出口，但因 await 不阻塞线程，V8 会为每一层递归保留 async 函数的执行上下文（含变量环境、Promise 状态、微任务入口），导致：
立即学习“Java免费学习笔记（深入）”；
- Promise 链深度随
n线性增长，每个 Promise 占用数百字节 - 所有中间层闭包持续引用其
n、参数、局部变量，无法 GC - 微任务队列持续膨胀（Chrome 中单次事件循环最多处理 2^31 个微任务，但远在此之前内存就爆了）
为什么不是栈溢出，而是内存溢出？
同步递归（如 function f(){f()}）会快速触发 RangeError: Maximum call stack size exceeded，因为调用栈是有限且连续的内存块。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
而 async/await 递归不占用 JS 调用栈（V8 将 async 函数编译为状态机，用堆内存管理状态），它把控制流拆成多个 Promise + 微任务。因此：
- 调用栈深度始终很浅（通常只有 1–2 层：event loop → microtask → async 函数体）
- 真正暴涨的是堆内存：每个未 resolve 的 Promise 实例、关联的闭包、微任务对象、内部状态机字段
- Chrome DevTools 的 Memory 面板会显示
Promise、AsyncFunction、Closure对象数量与大小持续飙升
真实可复现的 OOM 示例
以下代码在几秒内即可耗尽几百 MB 内存（取决于设备）：
async function boom(count = 0) {
const data = new Array(10000).fill('leak'); // 每层分配大对象
if (count > 10000) return;
await boom(count + 1); // 无 delay、无 cancel、无边界检查
}
boom(); // ⚠️ 不要直接运行！原因分析：
- 每轮递归都创建一个 10k 元素数组，被闭包捕获
-
await boom(...)返回的 Promise 在 resolve 前，整个闭包（含data）无法被垃圾回收 - 10000 层 ≈ 10000 × ~80KB ≈ 800MB 堆内存，触发 OOM 或页面无响应
如何安全替代：用 await + setTimeout / queueMicrotask 控制节奏
若必须递归处理大量数据，应主动切片 + 异步让出控制权，避免微任务雪崩：
async function safeRecursion(items, index = 0) {
if (index >= items.length) return;
<p>// 处理当前项（同步）
processItem(items[index]);</p><p>// ✅ 主动让出：下一轮推到宏任务末尾，清空微任务队列
await new Promise(resolve => setTimeout(resolve, 0));</p><p>// 继续递归（此时上层闭包已可被 GC）
return safeRecursion(items, index + 1);
}更优做法是改用迭代 + for await 或分批处理：
- 用
while+await sleep(0)替代递归 - 对大数据集使用
requestIdleCallback或setTimeout(..., 1)分帧处理 - 确保每次异步步骤后，前序作用域变量能脱离引用（例如将
data设为null或移出闭包）
