彻底搞懂 JS 尾调用与尾递归优化：概念、现状与工程方案

前两天有个朋友去面前端，被问到一道“送命题”：“JS 的尾调用优化你了解吗？”

他当场愣住，脑子里转了半天，最后憋出一句“就是函数最后调用一个函数，可以优化递归”。面试官追问了一句“那你们线上项目里用过吗”，他就彻底没声了。

回来之后他找我复盘，我就发现一件事：尾调用（Tail Call）、尾递归（Tail Recursion）、尾调用优化（TCO）这三个词，很多前端人听说过，但真正能讲清楚的没几个。更麻烦的是，网上大量资料把“ES6 支持尾调用优化”当成既定事实，而现实里主流浏览器压根没实现，面试官要是往深了问，十有八九要翻车。

这篇文章我就把尾调用这条线从头到尾捋一遍：概念是什么、浏览器现状如何、面试怎么答、没有引擎支持时怎么手动优化、以及我实测过的性能数据。不管你是准备面试，还是写递归写到爆栈想找人救命，这篇应该都能帮上忙。

1. 先把话说明白：尾调用到底是什么

1.1 一个定义和两个典型例子

尾调用的定义，一句话：函数的最后一步操作是调用另一个函数，并且这个调用的返回值直接作为当前函数的返回值返回。

听上去简单，但很容易踩坑。看两个栗子。

js复制// 这是尾调用
function foo(x) {
  return bar(x);
}

// 这不是尾调用
function foo(x) {
  const y = bar(x);
  return y + 1;
}

第一个例子里，bar(x) 的返回值原封不动地交给 foo 的调用者，foo 自己不需要再做任何计算，所以 bar(x) 处于尾部位置。第二个例子里，bar(x) 返回之后 foo 还要做一次 + 1，这个调用就不是尾调用。

有一个更隐蔽的坑是这种：

js复制function foo(x) {
  return bar(x) + 1; // 不是尾调用，因为 return 的是加法结果
}

function foo(x) {
  const y = bar(x);
  return y; // 这其实也不算标准的尾调用，因为多了一步变量赋值
}

很多人以为“只要写在最后一行就算尾调用”，这是错的。判断标准不是代码行数，而是返回值是否被原样 return、当前函数是否还需要继续执行。

另外还有一种情况容易误判，函数最后调用一个函数但没写 return，比如：

js复制function foo(x) {
  bar(x);
}

严格说 bar(x) 的结果会被丢弃，最后返回的是 undefined，所以这也不是尾调用。只有 return bar(x) 这种形式才算。

1.2 普通递归为什么会栈溢出

说完了定义，我们得聊聊普通递归为什么容易爆栈。

JS 在运行时有一个“调用栈”的概念。每次调用一个函数，引擎都会往栈上压一个“栈帧”，里面保存局部变量、参数、返回地址这些信息。函数执行完，栈帧弹出，回到上一层继续执行。

递归的问题在于：每一层递归都是“先调用，后收尾”，所以每一层的栈帧都不能提前释放。

js复制function sum(n) {
  if (n <= 0) return 0;
  return n + sum(n - 1);
}

这个 sum(5) 的调用过程大致是这样的：sum(5) 要先等 sum(4) 的结果，sum(4) 又要等 sum(3) 的结果……一层层压栈，直到最底层的 sum(0) 返回后，再一层层把结果加回来。所以当 n 很大时，栈帧数量直接跟递归深度成正比。

浏览器主线程的默认栈空间大概是 1MB 左右，每层递归栈帧消耗几十到几百字节，因此普通递归通常到几千层到几万层就会触发 RangeError: Maximum call stack size exceeded。不同机器和引擎有差异，我之前在 Chrome 里测过，一个极简递归函数大概 11000 层左右就爆了。

爆栈不是小事，它会把整段调用链直接中断，如果是在事件处理或者渲染流程里出现，页面体验基本就毁了。

1.3 尾调用优化：栈帧直接交接

尾调用优化要做的事，就是解决上面这个问题。

当一个函数 foo 的最后一步是 return bar(x) 时，foo 的调用者压根不需要 foo 再返回一个加工过的值，foo 的局部变量、内部状态对后续计算已经没用了。这时候引擎可以让 bar 直接复用 foo 的栈帧，而不是新压一个栈帧。

打个比方：普通调用流程像接力赛里每个队员都要先跑回起点拿接力棒再去下一棒，尾调用优化则像交接棒之后原地起跑，上一棒的任务已经彻底结束，他的位置可以直接让给下一棒。

这个优化对递归特别有价值。如果写成尾递归，递归深度就是常数级，理论上栈空间 O(1)，无论 n 多大都不会爆栈。

尾递归就是尾调用的特例：函数在尾部位置调用它自己。比如：

js复制function sumTail(n, acc = 0) {
  if (n <= 0) return acc;
  return sumTail(n - 1, acc + n);
}

逻辑上等价于循环，每次调用通过参数把中间结果传下去，不需要回溯。这样如果引擎支持 TCO，就永远不会爆栈。

2. 到了 JS 这里，情况为什么变得尴尬

2.1 规范写过，但引擎没跟上

这里要澄清一个流传很广的误解：“ES6 支持尾调用优化”。

ES2015 的规范文档里确实写了 Proper Tail Calls（PTC），并要求引擎实现。这是真的。但问题在于，规范和引擎实现是两回事。V8（Chrome 和 Node.js 的引擎）、SpiderMonkey（Firefox 的引擎）从一开始就对 PTC 持拒绝态度，并且一直没实现。

后续 TC39 委员会面对主要引擎集体“不配合”的现实，也把 TCO 从强制要求中放了下来。现在你去看主流浏览器的行为，基本可以认为：在真实前端环境里，语言层面的尾调用优化约等于不存在。

所以面试时如果你说“ES6 支持尾调用优化，所以递归不会爆栈”，面试官只要让你现场跑一下，你就得很尴尬地承认“我用的浏览器没实现”。这种“背过规范但没验证过实现”的回答，是面试里最容易被戳穿的。

2.2 V8 不做的理由：堆栈和调试

V8 团队当年公开解释过为什么不做 Proper Tail Calls，理由其实很实际：

第一，TCO 会让错误堆栈变短。本来你可以看到从 foo 到 bar 到 baz 的完整调用链，优化之后中间的帧被复用，出错时只看到最外层或被调用的一方，排查问题变得很难受。

第二，调试器不太好干活。开发者试图在中间某层递归打断点、查看当时的局部变量，如果栈帧被复用，这些帧根本不存在，调试体验大打折扣。

第三，它会影响 JIT 优化策略。强制在所有尾位置做栈帧复用，引擎在编译优化时反而会受到约束。

说白了，V8 团队认为 TCO 带来的“栈安全”收益，抵不上调试和错误排查的损失。这个取舍也不是没有道理，只是苦了那些想写深递归的人。

2.3 Safari 曾经是独苗

不是说所有引擎都没实现过。Safari 使用的 JavaScriptCore 引擎，曾经是唯一一个认真落地 Proper Tail Calls 的主流引擎。

但这个故事也没有一个圆满结局。TCO 在真实浏览器里会改变堆栈的行为，一些网站依赖错误调用栈做上报或逻辑判断，TCO 上线后反而出过兼容性问题。后来 WebKit 生态对 TCO 的态度也变得反复，你在今天的 Safari 上跑深层递归，一样会爆栈。

所以结论是：开发时不要把任何浏览器版本的 TCO 当成可依赖的能力。写代码时假设它不存在，获得优化就当惊喜，不获得也不会出问题。

2.4 严格模式：一个容易被忽略的前提

就算某个环境支持尾调用优化，还有一个隐藏条件：规范里的 Proper Tail Calls 只在严格模式下生效。

原因也不复杂。非严格模式下有 function.caller 和 arguments.callee 这类机制，调用方和被调用方能互相追溯。TCO 的本质是复用栈帧，一旦帧被复用了，调用关系就“断”了，这类兼容性语义没法维持。所以规范才把 TCO 限制在严格模式代码里。

这给面试回答提了个醒：如果面试官问“尾调用优化什么时候生效”，你补一句“严格模式下”会很加分。

3. 面试官问你“能不能优化递归”，到底想听什么

3.1 先会写一个标准的尾递归

面试里最常见的场景，是让你优化一个递归函数。这时候你得能快速写出尾递归版本。

阶乘是标配题：

js复制// 普通递归
function factorial(n) {
  if (n <= 1) return 1;
  return n * factorial(n - 1);
}

// 尾递归版本，用第二个参数保存累计结果
function factorialTail(n, acc = 1) {
  if (n <= 1) return acc;
  return factorialTail(n - 1, n * acc);
}

斐波那契数列也常考。普通递归是指数级复杂度，改成尾递归后变成线性：

js复制// 普通递归，O(2^n) 复杂度
function fib(n) {
  if (n <= 1) return n;
  return fib(n - 1) + fib(n - 2);
}

// 尾递归版本，用两个参数保存前两个状态
function fibTail(n, a = 0, b = 1) {
  if (n === 0) return a;
  return fibTail(n - 1, b, a + b);
}

观察这两个版本的共同点：中间结果全部通过参数传递，不用依赖返回值回溯。这就是“累加器”思想，面试时能把这个思路讲清楚，比背代码重要得多。

3.2 重点：写成尾递归不等于拿到优化

接下来这个坑很关键，我必须单独说：在目前主流 JS 引擎里，你写上尾递归写法，也依然会爆栈。

我之前在 Chrome 里跑过这个：

js复制function sumTail(n, acc = 0) {
  if (n <= 0) return acc;
  return sumTail(n - 1, acc + n);
}

sumTail(100000); // RangeError: Maximum call stack size exceeded

虽然它是标准尾递归，但因为 V8 没有真正的 TCO，引擎依然老老实实地一层层压栈，该爆还是爆。

所以面试回答的正确姿势是：先展示你会写尾递归版本，表示你理解这个优化思路；然后主动说明“尾递归写法在支持 TCO 的引擎里可以避免栈溢出，但今天的主流浏览器默认没有实现，所以实际工程里我会配合循环或蹦床函数来保证安全性”。这一套组合拳打下来，面试官会觉得你既懂理论、又懂实现、还懂工程取舍，基本满分。

3.3 面试官真正的考察点

面试官问尾调用，通常不是真想让你解释一个冷门语言特性，而是在考察三件事：

一是基础功底。你懂不懂调用栈、栈帧、递归的空间复杂度，这些是计算机基础能力的直接体现。

二是对“规范 vs 实现”的分辨能力。前端人有太多“背规范”的坏习惯，尾调用是个很经典的例子，规范写了、引擎没做，能答出这一层差异的人，说明真的研究过运行时，而不是只刷过八股。

三是优化意识。遇到递归爆栈，你会不会找替代方案？是硬莽一个尾递归，还是能想到蹦床函数、循环改写、显式栈这些工程手段。这里考察的是解决问题的能力。

所以别把尾调用当成一个孤立的面试题，它就是一面镜子，照出你平时写代码时对自己运行环境理解得有多深。

4. 没有 TCO，怎么手动保命

前面说了这么多坏消息，现在来点实用的。既然引擎不帮忙，我们就自己动手。

4.1 方案一：蹦床函数

蹦床函数（Trampoline）是一种经典的手动模拟 TCO 的手段。思路很简单：把每次递归调用包装成一个函数，外层用循环不断执行这个函数，直到返回一个非函数值。这样就把“递归调用”变成了“循环迭代”，栈不会增长。

js复制function trampoline(fn) {
  return function (...args) {
    let result = fn.apply(this, args);
    while (typeof result === 'function') {
      result = result();
    }
    return result;
  };
}

function sumTail(n, acc = 0) {
  if (n <= 0) return acc;
  return () => sumTail(n - 1, acc + n);
}

const safeSum = trampoline(sumTail);

console.log(safeSum(100000)); // 5000050000

注意 sumTail 返回值从数字变成了一个箭头函数，外层 trampoline 不断执行这个函数，直到某个递归终点返回数字为止。这样无论 n 多大，循环里的调用栈深度都只有一层。

蹦床函数的优点是代码改动不大，保留递归的形态，理解起来比较直观。缺点也很明显：每一步都要创建一个新闭包，产生大量临时对象，性能比纯循环差不少，GC 压力也比较大。所以它适合处理“深度不可控但调用不频繁”的场景，不适合做热路径上的核心算法。

4.2 方案二：直接改成循环

说实话，工程上最稳的方案反而是最土的：能改循环就改循环。循环不需要创建额外函数对象，没有递归调用开销，V8 对循环的优化也最成熟。

js复制function sumLoop(n) {
  let acc = 0;
  while (n > 0) {
    acc += n;
    n--;
  }
  return acc;
}

树形结构遍历也同理。深层递归遍历 DOM 或树的时候，可以用显式栈替代系统调用栈：

js复制function deepTraverse(root) {
  const stack = [root];
  while (stack.length) {
    const node = stack.pop();
    visit(node);
    if (node.children) {
      for (let i = node.children.length - 1; i >= 0; i--) {
        stack.push(node.children[i]);
      }
    }
  }
}

“换成循环”听起来低级，但在前端场景里这是最可靠、性能最好、最好调试的做法。面试时如果你能说出“我一般先尝试改循环，因为浏览器对循环优化更好”，面试官通常不会觉得你思路平庸，反而会觉得你务实。

4.3 方案三：把递归状态变成状态机

有些递归逻辑比较复杂，直接改成 while 循环会丢失结构，你可以把“递归的每一层状态”抽出来，用一个对象或者闭包保存，再用循环手动推进。

js复制function stateMachine(n, acc = 0) {
  let state = { n, acc };
  while (state.n > 0) {
    state = { n: state.n - 1, acc: state.acc + state.n };
  }
  return state.acc;
}

本质上这就是把递归“状态化”，每一轮迭代产出下一个状态。好处是状态对象可序列化、可调试，适合复杂算法或者需要中途暂停恢复的场景。坏处是代码比循环啰嗦，需要多写一个状态转换函数。

4.4 四种方案怎么选

我自己的选型逻辑大致是：

前端日常场景，我强烈建议默认选第二种或第三种，简单直接、性能有保障。蹦床函数更适合在一个已经写成递归风格的模块里做最低成本改造，不建议大规模铺开。

5. 实测一次：到底谁快、谁稳

5.1 基准测试设计

光说不练假把式。我在本机用 Node 跑了一组对比测试，分别测试普通递归、尾递归写法、蹦床函数、循环，计算 1 到 n 的累加和。

js复制function sumRec(n) {
  if (n <= 0) return 0;
  return n + sumRec(n - 1);
}

function sumTail(n, acc = 0) {
  if (n <= 0) return acc;
  return sumTail(n - 1, acc + n);
}

function trampoline(fn) {
  return function (...args) {
    let result = fn.apply(this, args);
    while (typeof result === 'function') {
      result = result();
    }
    return result;
  };
}

function sumTramp(n, acc = 0) {
  if (n <= 0) return acc;
  return () => sumTramp(n - 1, acc + n);
}

function sumLoop(n) {
  let acc = 0;
  while (n > 0) {
    acc += n;
    n--;
  }
  return acc;
}

测试时，普通递归和尾递归写法在 n=100000 时都会爆栈，所以我用 n=10000 测这两组；蹦床和循环用 n=100000 测。每种跑多轮取大概量级。

5.2 结果和解读

我本地跑了之后，结果基本符合预期：

这两个结果很能说明问题：

第一，普通递归和“尾递归写法”在 V8 里性能几乎没差别，因为引擎根本没做优化，两者都是正常递归调用。很多人以为把递归改成尾递归写法就会变快，在 V8 里这是错觉。

第二，蹦床函数虽然栈安全，但性能比循环差了一两个数量级，因为它每次迭代都创建闭包再调用，GC 压力大。

第三，循环在两个维度上都赢：又快又稳。所以实际工程里，能用循环就别硬拗递归。

5.3 什么时候才值得谈“尾调用性能”

那你可能会问，既然循环那么香，尾调用这个概念还有什么用？

我的看法是：当你用一种偏函数式的编程风格时，比如大量使用不可变数据、组合函数、递归遍历结构树，尾递归可以让你保持表达力；在已知支持 TCO 的运行环境（比如某些服务端引擎或者特定编译目标）里，它的栈安全优势也能兑现。另外在纯算法讨论、编译器设计、函数式语言对比这些语境下，尾调用依然是核心概念。

但前端网页这种环境，性能瓶颈绝大多数不在递归上，而在 DOM 操作、网络请求、渲染周期那里。与其花力气把一个递归改成蹦床函数，不如先想想这个递归真的需要存在吗。优化之前先测量，这是我一直以来的原则。

6. 面试速查和避坑清单

6.1 几个高频问题速答

这里整理了一张速查表，面试前扫一眼就够了。

6.2 容易被带偏的表述

有些资料里会出现一些看上去很高级、实则容易误导的说法，建议心里有数。

“写成尾递归后性能会变快”是错的。在没有 TCO 的引擎里，尾递归写法和普通递归性能一样；在支持 TCO 的引擎里，收益主要是避免栈溢出，栈帧复用也能减少内存访问，但不会改变算法的时间复杂度。

“TCO 能解决所有递归问题”也是错的。递归性能差的根本原因之一是指数级重复计算，比如朴素的斐波那契递归，就算有 TCO 救了栈，复杂度依然爆炸。尾递归优化只是解决“栈空间”问题，不是万能药。

还有一点要注意：CPS（Continuation-Passing Style）变换是讲座级概念，经常和尾调用一起出现。把递归改成 CPS 后，如果引擎没有 TCO，那些闭包会堆积在堆上，照样内存暴涨。所以面试时提一嘴可以，别把它当成工程优化方案。

6.3 我自己面试时怎么答

如果被问到“尾调用优化”，我大概会这样组织回答：

“先分清两个概念，尾调用是函数最后的 return 语句里调用了另一个函数，尾递归是尾调用发生在自身调用上。所谓优化，就是让被调用函数复用当前栈帧，从而把递归的栈空间从 O(n) 降为 O(1)。不过这个优化在 ES6 规范里是写了，但 V8 和 SpiderMonkey 都没实现，Safari 的 JavaScriptCore 曾实现过但后来默认也关了，所以前端环境里没法依赖它。实际写代码时我会在需要大深度递归的地方用迭代循环、显式栈或者蹦床函数来保证不爆栈，同时性能也可控。”

这个回答既讲了定义，又讲了原理，又讲了实现现状，还给出了工程方案，逻辑完整，不会被追问到哑火。

7. 最后分享一点我的心得

说实话，我在刚接触尾调用的时候也走过弯路，以为背下“尾递归防爆栈”就能解决所有问题，结果第一次写深递归在 Chrome 里直接报 RangeError，才发现规范和实现之间有这么大一条鸿沟。

从那之后我养成了一个习惯：凡是面试题里出现的“规范特性”，我都会去实际跑一遍，确认哪条在浏览器里真的生效。尾调用优化是我踩过的比较典型的一个坑，类似的还有各种新 API 的兼容性问题、严格模式的行为差异，都属于“书上说可以，跑起来不一定”的范畴。

如果你现在正在准备前端面试，我建议把尾调用当成一个范例来理解：概念要清楚，原理要能讲，实现现状要知道，工程方案要能写。这几个层面都覆盖到之后，面试官再追问什么角度你都能接住。

最后再送一个小技巧：面试时如果被问到你不确定的性能特性，坦诚说“我在实际环境里测过，表现是 XXX，因此我不会在线上依赖它”，比硬着头皮背书里的结论要可信得多。面试官也是从一线走过来的，好不好忽悠，他一眼就能看出来。