函数式编程中，递归是表达算法的自然方式，但传统递归极易因深度调用导致栈溢出。尾调用优化（TCO）是编译器的一项关键技术，能在语义不变前提下复用栈帧，将递归转化为循环。然而，多数主流语言（如JavaScript、Python）并未原生支持完全TCO。此时，延续传递风格（CPS）变换成为工程落地的救命稻草——它通过显式传递“后续计算步骤”，强制将任意递归转为尾递归形式，再配合Trampoline循环执行，彻底规避栈增长。本文不谈理论推导，直击工程实现：提供参数结构、代码模板与性能权衡清单，助你在无TCO环境中安全落地深度递归。
CPS变换的核心约定极为简单：为每个函数增加一个名为kont（continuation的缩写）的参数，它是一个单参数函数，负责接收当前计算结果并执行后续所有操作。例如，普通阶乘函数fact(x) = x * fact(x-1)经CPS变换后变为fact(x, kont) = fact(x-1, res => kont(x * res))。这里，res => kont(x * res)就是新的continuation：它接收子调用结果res，乘以x后再交给上层kont。关键在于，对kont的调用必须是函数体的最后一个动作——这天然满足尾调用条件。正如博客园文章所指出：“CPS约定简约，却可显式地控制程序的执行……程序里各种形式的控制流都可以用它来表达。” 通过这种变换，所有函数调用都被迫转为尾调用，为后续优化铺平道路。
但仅有CPS还不够。在无TCO的语言中，解释器仍会为每个尾调用分配栈帧，最终导致栈溢出。此时需引入Trampoline（蹦床）机制：它是一个循环驱动器，负责“弹跳”执行continuation链，而非依赖函数调用栈。实现Trampoline有两种主流方式。方式一：显式状态对象。定义trampoline(kont_v)函数，其参数kont_v是包含{kont: Function, v: any}的对象。循环体内不断执行kont_v = kont_v.kont(kont_v.v)，直到kont为null，返回最终值v。对应的CPS函数需返回此类对象，如sum_bounce(x, kont) = { kont: r => sum_bounce(x-1, res => ({ kont, v: res + x })), v: null }。方式二：利用bind与闭包。定义trampoline(kont)，循环执行kont = kont()直到返回非函数值。CPS函数则返回绑定参数的函数，如sum_bounce(x, kont) = sum_bounce.bind(null, x-1, res => kont.bind(null, {val: res.val + x}))。后者更简洁，但需注意结果包装（如{val: ...}）以区分函数与普通值。
以下是可直接复用的工程参数清单：
- CPS函数签名：
(input: T, kont: (result: R) => any) => { kont: Function, v: any } | Function。kont必须是单参函数，承担所有后续计算。
- Trampoline入口：
function trampoline(initialKontV)。初始调用传入{kont: res => ({ kont: null, v: res }), v: null}或等价闭包。
- 内存监控点：continuation链长度 = 递归深度。每层链消耗堆内存约几十至数百字节（取决于闭包捕获变量），需预估最大深度×单层开销，设置进程内存上限。
- 性能回滚阈值：若递归深度 > 10,000，优先考虑改写为迭代算法。CPS+Trampoline时间复杂度不变，仅空间从栈转堆，深度过大时堆内存与GC压力剧增。
- 调试开关：在kont函数内添加计数器或日志，记录已执行步数，便于定位死循环或性能瓶颈。
必须正视其代价。CPS变换并未降低算法时间复杂度，仅将栈空间压力转移至堆内存。对于树状递归（如Fibonacci），堆内存消耗可能随深度指数增长，导致程序卡死而非优雅失败。此外，代码可读性严重受损——“内层函数被外层函数的参数分在两端包裹住，不符合人类的线性思维”，调试与维护成本陡增。因此，它应作为最后手段：当算法无法轻易转为迭代、且语言无TCO支持时，才祭出此方案。在支持TCO的语言（如Scheme、Erlang）或可手动标注尾递归的环境（如Scala @tailrec），应优先使用原生优化。
总结落地路径：先对目标函数进行CPS变换，添加kont参数并确保所有调用均为尾调用；再选择Trampoline实现方式（推荐显式对象版，调试友好）；最后注入监控与回滚策略。记住，CPS不是银弹，而是特定约束下的工程妥协。掌握其参数与权衡，方能在栈溢出的悬崖边安全行走。