蹦床函数的核心价值是让深度递归在不支持尾调用优化（tco）的环境里安全运行——它不改变算法逻辑，只把“调自己”变成“返回一个待执行的函数”，再由外层循环统一驱动，从而把调用栈压到恒定1～2层，彻底避开rangeerror或recursionerror。
蹦床函数的核心价值是让深度递归在不支持尾调用优化（TCO）的环境里安全运行——它不改变算法逻辑，只把“调自己”变成“返回一个待执行的函数”，再由外层循环统一驱动，从而把调用栈压到恒定 1～2 层，彻底避开 RangeError 或 RecursionError。
它解决的是“不能改写逻辑，但又必须防爆栈”的真实困境
不是所有递归都能轻松转成迭代。比如解析嵌套 JSON、遍历 DOM 树、规则引擎里的条件链展开，这些场景天然递归、结构动态、状态难枚举。硬改成迭代往往要手动维护多个栈或队列，代码复杂度飙升，还容易出错。蹦床让你保留原有递归结构，只需两处改动：函数内部返回 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 和后期维护成本，更容易成为长期瓶颈。
