蹦床函数与事件循环优先级控制

蹦床函数（Trampoline）要解决的根本问题，其实是递归调用太深导致的栈溢出错误。它的做法非常干脆：每次递归调用不再真正压入调用栈，而是返回一个 thunk 函数（一个待执行的包装函数），然后由外层循环反复执行这些 thunk。这样一来，调用栈始终保持在恒定深度，全程同步运行，跟事件循环（Event Loop）的调度机制毫不相干。

严格来说，蹦床函数和事件循环的优先级调度完全不沾边。它并不是用来控制宏任务（MacroTask）与微任务（MicroTask）执行顺序的，而是一种手动控制调用栈深度的纯编程技巧——说白了，就是为了防止栈溢出，而不是干预 JavaScript 事件循环的执行流程。

蹦床函数解决什么问题？

当函数递归层级过深时，调用栈可能超出 JavaScript 引擎的限制，抛出 RangeError: Maximum call stack size exceeded。蹦床函数的核心思路是将递归改写为循环：每次“递归调用”变成一个返回函数（thunk）的行为，外层的 while 循环挨个执行这些 thunk，从而把调用栈彻底压平。

• 它不会引入任何异步操作，也不会向任务队列投递任何任务
• 全程运行在同步上下文当中，属于纯粹的计算优化手段
• 不会触发 Promise.then、setTimeout 或 queueMicrotask 等异步调度机制

事件循环优先级由什么决定？

真正决定 JavaScript 执行顺序的，是任务类型的划分以及事件循环自带的固有规则：

• 同步代码：立即进入调用栈，按代码书写顺序依次执行
• 微任务（如 Promise.then、queueMicrotask、MutationObserver）：当前宏任务结束后，会立刻全部执行完毕，清空微任务队列
• 宏任务（如 setTimeout、setInterval、I/O、UI 渲染）：每次事件循环只从宏任务队列中取出一个任务执行，执行前会先完成渲染（浏览器环境）

这个优先级链条是由 JavaScript 引擎强制保证的，蹦床函数根本改变不了它。

想控制执行时机？用对工具

如果你的目标是“延迟执行”或“提升响应优先级”，那得靠事件循环原生支持的机制，而不是蹦床函数：

• 需要比 setTimeout 更快执行？用 queueMicrotask(fn) —— 它属于标准微任务，紧接在当前同步代码之后、下一个宏任务之前执行
• 需要等 DOM 渲染完成后再执行？用 requestAnimationFrame（渲染前回调）或 setTimeout(fn, 0)（后者仍然是宏任务，会在下一轮事件循环执行）
• 想拆分长任务避免主线程阻塞？用 setTimeout 或 queueMicrotask 进行任务切片，而不是依赖蹦床函数

两者混合使用的注意点

蹦床函数内部若包含了异步操作（比如在 thunk 里调用了 fetch 或 Promise），那么只有异步部分才会进入事件循环调度；蹦床本身只是让那一层“调度逻辑”保持同步执行，不会改变异步任务的优先级。

• 常见误解：“用蹦床函数可以让 Promise 回调更快执行”——实际无效，Promise.then 始终是微任务，跟外层是否使用蹦床毫无关系
• 合理场景：用蹦床函数处理大量同步计算（例如深度递归遍历），再借助 queueMicrotask 交还主线程控制权，从而避免界面卡顿或长时间无响应