在讨论蹦床函数之前，需要先了解一个常见痛点：某些递归逻辑因为业务需要无法轻易改写，但运行环境却不支持尾调用优化（TCO）。若强行递归，随着深度增加，很可能触发 RangeError 或 RecursionError，导致程序崩溃。蹦床函数的巧妙之处在于——它无需改变原有的算法结构，仅将“函数直接调用自身”转变为“函数返回一个待执行的函数”，再由外层循环统一调度执行。这样，调用栈深度被稳定控制在1~2层，即使递归深度极大也能安全运行。
简而言之，蹦床函数的核心价值在于：在缺少尾调用优化支持的运行环境中，它能让深度递归安全执行。原理是不修改算法逻辑，仅将“递归调用自身”改为“返回一个待执行的函数”，然后借助外层循环统一驱动，使调用栈始终保持在1～2层，从而有效避免 RangeError 或 RecursionError。
它解决的是“不能改写逻辑，但又必须防爆栈”的真实困境
并非所有递归都能轻易转换为迭代。例如解析嵌套 JSON、遍历 DOM 树、规则引擎里的条件链展开，这些场景本质上是递归的，结构动态且状态难以枚举。若强行改为迭代，往往需要手动维护多个栈或队列，导致代码复杂度急剧上升，且容易引入 bug。蹦床函数允许你保留原有的递归结构，仅需两处调整：在函数内部返回 thunk（如 () => next(...)），调用时包裹一层 trampoline(() => fn(...))。
- 返回的是函数而非结果，执行权交给 while 循环，而非压入新栈帧
- 所有递归路径必须统一返回函数，否则循环会提前结束
- thunk 内不能包含运行时求值参数（例如
() => f(x, y)可行，f(x)(y)则不行）
性能对比关键看三个维度：栈开销、堆开销、可读性成本
实际上，蹦床与迭代并非简单的“谁更优”问题，而是“在不同约束下哪种方案更合适”：
- 栈空间：蹦床稳定 O(1)，迭代也是 O(1) 或可控 O(depth)；原生递归为 O(n)，n 过大时直接崩溃
- 堆空间：蹦床每次返回新函数对象，会产生少量闭包对象（JS）或 lambda 实例（Python），带来轻微 GC 压力；迭代通常只需几个变量，堆开销几乎为零
- 可读性与维护成本：蹦床版本代码与原始递归几乎一致，调试时堆栈清晰；迭代版本常需额外状态变量、显式栈/队列、多分支判断，逻辑分散，修改风险较高
什么时候选蹦床？什么时候选迭代？
判断依据是问题本质，而非单纯看“是否为递归”：
- 选蹦床：递归深度不可控（例如用户输入决定嵌套层数）、业务逻辑强依赖递归语义（如 AST 遍历、正则匹配回溯）、重构成本高或不允许改动核心逻辑
- 选迭代：结构固定（如数组遍历、最多5层配置）、性能敏感（高频调用、嵌入式环境）、团队对显式状态管理更熟悉
实测差异往往不如预期大
在多数业务场景中，蹦床带来的微小堆分配开销远小于一次 DOM 操作或网络请求。真正的性能瓶颈通常来自算法复杂度本身，而非蹦床调度器中那几行 while 循环。V8 和 Python CPython 对闭包及 lambda 的优化已相当成熟，只要不滥用（例如每层都 new 一个大对象），实际性能差异几乎可以忽略。相比之下，迭代版本因逻辑拆散导致的 bug 和后期维护成本，更容易成为长期的性能瓶颈。
