识别递归函数是否需栈溢出防御，关键看调用深度是否可控及环境是否支持尾调用优化；蹦床生效需同时满足返回函数表达式和trampoline调度器驱动。

识别递归函数在高阶应用中是否需要栈溢出防御，关键不在于“是不是递归”，而在于“调用深度是否可控、执行环境是否支持尾调用优化”。蹦床函数不是万能补丁，而是针对特定风险场景的精准干预手段。

看调用链是否隐式嵌套过深

高阶函数（如 map、filter、compose、递归式柯里化）容易把多层逻辑压缩进单次调用，表面看只调了一次，实际内部可能触发数十甚至数百层递归。例如：

• 用 递归实现的 JSON 深拷贝 处理含 10 层嵌套对象的配置项；
• 用 组合函数 compose(f, g, h, ...) 构建 50+ 函数串联的 pipeline；
• 在事件总线或响应式系统中，依赖追踪引发的递归求值链 不易被静态识别。

这类场景下，即使单个函数是尾递归形式，运行时仍可能爆栈——因为 JavaScript 引擎（如 V8）默认不启用尾调用优化（TCO），且高阶抽象掩盖了真实调用深度。

看函数返回值是否为“可执行单元”

蹦床函数起效的前提，是递归函数主动放弃立即执行权，改用“返回函数”来表达下一步计算。识别方式很简单：检查递归分支的 return 表达式是否形如：

• return sum.bind(null, x + 1, y - 1)
• return () => even(n - 1)
• return partial(odd, Math.abs(n) - 1)

只要看到 return 后跟的是函数创建（箭头函数、bind、partial、闭包等），而非直接调用 fn(...)，就说明已适配蹦床模式。这是人为引入的“控制流断点”，也是防御栈溢出的第一道信号。

看执行入口是否包裹 trampoline 调度器

光有“返回函数”不够，还必须有统一调度器来接管执行流。典型识别标志是存在一个中心化循环，持续解包并执行函数，直到返回非函数值：

• while (f && typeof f === 'function') { f = f(); }
• for (; f instanceof Function; f = f()) {}
• Gleam 中类似 loop { case next() { #done(v) -> v #more(f) -> next = f } }

如果没有这层循环兜底，那些返回的函数只是被创建后闲置，根本不会执行，更谈不上防溢出。因此，**蹦床是否生效，取决于“构造”和“驱动”两个环节是否同时存在**。

看错误是否稳定复现于大输入但不崩溃小输入

这是最直接的线上识别方式。当函数在处理小数据（如 n=100）时正常，但在 n=10000 或嵌套层级 ≥20 时稳定报 RangeError: Maximum call stack size exceeded，且堆栈轨迹显示重复出现同一函数名（如反复出现 fib、traverse、reduceDeep），基本可判定为栈溢出。此时若代码已按蹦床模式重构，但仍未加 trampoline() 包裹调用，就是典型的“半成品防御”。