蹦床函数是同步while循环，栈深恒为1但会阻塞主线程；为实现非阻塞深度遍历，需用queuemicrotask将每步“弹跳”推入微任务队列，让出控制权以支持渲染和交互响应。
蹦床函数本身不直接运行在微任务队列中，它是一个同步的循环执行机制；但若想实现真正非阻塞的深度遍历，常需主动将每一步“弹跳”推入微任务队列（如用 queueMicrotask），从而让出主线程控制权。
蹦床是同步循环，不是微任务
标准蹦床函数（trampoline）本质是一个 while 循环：接收一个 thunk（函数），执行它，检查返回值是否仍是 thunk；如果是，继续执行；否则返回结果。整个过程在单次调用中完成，不涉及事件循环调度，属于同步代码，会持续占用调用栈——只是栈深恒为 1，不会溢出。
它解决的是栈空间爆炸问题，而非主线程阻塞问题。
微任务切片：让蹦床“呼吸”
当遍历层级极深（比如上万层树节点）时，即使栈不溢出，连续同步执行也会阻塞渲染、输入响应等宏任务。此时需把每次“弹跳”拆成独立微任务：
- 不用 while 循环驱动，而是每次只执行一个 thunk，然后用 queueMicrotask 调度下一步
- 这样每步之间都会回到事件循环，允许微任务队列清空、触发渲染、响应用户操作
- 相当于把一个长同步任务，切成多个微任务片段，在本轮循环末尾依次执行
和 Promise.then 的区别
有人用 Promise.resolve().then 实现类似效果，但要注意：
- Promise.then 会创建新 promise 链，有额外开销；queueMicrotask 更轻量、语义更清晰
- 两者都属于微任务，执行时机一致：当前宏任务结束后、渲染前，一次性清空队列
- 但若在微任务里又不断注册新微任务（如无节制递归调用 queueMicrotask），就会导致微任务队列过长，延迟渲染甚至卡死 UI
实际写法示意
例如遍历一棵深树：
function traverse(node) {
if (!node) return;
// 处理当前节点
process(node);
// 下一步交给微任务，不阻塞主线程
if (node.left) queueMicrotask(() => traverse(node.left));
if (node.right) queueMicrotask(() => traverse(node.right));
}
这已不是传统蹦床，而是“微任务驱动的递归展开”。它放弃了单栈优势（因每次调用仍进栈），但换来了非阻塞性；若要兼顾两者，可结合 thunk + queueMicrotask 手动控制节奏。
