微任务中递归不会爆栈的前提是伪递归（如queuemicrotask），每次执行为独立栈帧；若同步调用自身则仍是真递归，必然导致栈溢出。
在微任务中递归触发不会直接导致调用栈溢出，因为微任务本身不增加同步调用栈深度；但若微任务内同步递归调用自身函数（而非通过 queueMicrotask 或 Promise.then 延迟），仍会爆栈——这是常见误解的根源。
微任务里“递归”的两种本质不同场景
必须区分清楚：
-
伪递归（安全）：用
queueMicrotask(fn)或Promise.resolve().then(fn)把下一次执行推入微任务队列。每次执行都是新调用、独立栈帧，前一次已出栈。不会爆栈。 -
真递归（危险）：在微任务回调里直接调用自己，比如：
fn() { ... fn(); }。这仍是同步递归，和普通函数递归无异，照样压栈，必然爆栈。
典型错误写法：看似“放微任务”，实则同步递归
下面这段代码看似用了微任务，实际仍爆栈：
function badRecursion(n) {
if (n badRecursion(n - 1));
}
badRecursion(20000); // 仍可能爆栈（取决于引擎对 then 的实现优化，但不可靠）原因：虽然 .then 是微任务，但 badRecursion(n - 1) 是在 .then 回调内部同步执行的，回调函数本身形成新的同步调用链。
正确做法：确保每次递归都脱离当前调用栈
真正安全的微任务递归，必须让每次逻辑运行都在一个全新的微任务中启动：
- 用
queueMicrotask显式排队，且函数体不包含任何同步递归调用 - 把状态（如
n、acc）作为参数传入，不依赖闭包堆叠
function safeRecursion(n, acc = 0) {
if (n safeRecursion(n - 1, acc + n));
}
safeRecursion(100000); // 不会爆栈为什么不用 setTimeout？它更慢但更稳
setTimeout(fn, 0) 属于宏任务，延迟更高（至少 4ms），但它天然隔开调用栈，适合超深递归兜底。而微任务虽快，但若大量连续入队，可能阻塞主线程响应（如卡住用户交互）。生产环境建议：
- 深度可控时优先用
queueMicrotask - 深度极大或需中断/节流时，改用
setTimeout并配合深度分片（如每 1000 层切一次）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
