JavaScript 中的尾调用优化（Tail Call Optimization）：探讨词法环境（Lexical Environment）在栈帧复用中的限制

各位同仁，各位编程爱好者，大家好！

今天，我们共同探讨一个在 JavaScript 领域备受关注，却又充满争议的技术话题：尾调用优化（Tail Call Optimization, TCO）。具体地，我们将深入剖析为何这项在许多函数式编程语言中司空见惯的优化，在 JavaScript 中却迟迟未能得到普适性的实现，其核心障碍正是在于 JavaScript 独特的词法环境（Lexical Environment）机制与栈帧复用之间的内在冲突。

我将以讲座的形式，从最基础的概念入手，逐步深入到问题的核心，并辅以丰富的代码示例，力求逻辑严谨，表达清晰。

---

引言：递归的困境与优化的渴望

在函数式编程范式中，递归是一种优雅而强大的问题解决方式。然而，传统的递归实现有一个广为人知的缺点：它会不断地在调用栈上累积新的栈帧。当递归深度过大时，这会导致栈溢出（Stack Overflow）错误，使得程序崩溃。

例如，一个简单的阶乘函数：

function factorial(n) {
  if (n === 0) {
    return 1;
  }
  return n * factorial(n - 1);
}

// console.log(factorial(5)); // 120
// console.log(factorial(10000)); // Uncaught RangeError: Maximum call stack size exceeded

当 n 足够大时，上述代码就会抛出 RangeError。为了解决这个问题，尾调用优化应运而生。

尾调用优化是一种编译器或解释器优化技术，它能识别并优化那些以“尾调用”形式存在的函数调用。其核心思想是，当一个函数的最后一个操作是对另一个函数的调用，并且该调用的结果直接作为当前函数的返回结果时，当前函数的栈帧就可以被复用或直接丢弃，而无需在调用栈上创建新的栈帧。这有效地将递归转换成了迭代，从而避免了栈溢出。

然而，尽管 ES6 标准曾尝试引入对尾调用的支持，但最终由于复杂性、一致性以及与 JavaScript 核心语义的潜在冲突，这项特性并未得到广泛实现，甚至在后续的规范修订中被降级处理。其中，词法环境的机制是阻碍其实现的关键因素。

---

一、理解函数调用栈与栈帧

要理解 TCO，我们首先需要回顾一下函数调用在计算机底层是如何工作的。

当一个函数被调用时，操作系统或运行时环境会在程序的调用栈（Call Stack）上创建一个新的记录，这个记录被称为“栈帧”（Stack Frame）或“活动记录”（Activation Record）。每个栈帧都包含了执行该函数所需的所有信息，例如：

1. 返回地址（Return Address）：函数执行完毕后，程序应该回到哪里继续执行。
2. 函数参数（Arguments）：传递给函数的参数值。
3. 局部变量（Local Variables）：函数内部声明的变量。
4. 保存的寄存器状态（Saved Registers）：在函数调用前保存的 CPU 寄存器值，以便函数返回时恢复。
5. 指向前一个栈帧的指针（Frame Pointer）：用于维护栈帧链。
6. 指向当前函数词法环境的引用（Lexical Environment Reference）：这是我们今天讨论的重点，它决定了函数如何访问变量。

考虑以下简单的函数调用链：

function funcA() {
  let a = 1;
  funcB();
  console.log('Back in funcA');
}

function funcB() {
  let b = 2;
  funcC();
  console.log('Back in funcB');
}

function funcC() {
  let c = 3;
  console.log('In funcC');
}

funcA();

当 funcA() 被调用时，调用栈的变化大致如下：

调用栈状态	描述
[global]	程序启动，全局作用域。
[funcA]	funcA 被调用，一个新的栈帧被推入栈顶。包含 funcA 的局部变量 a，返回地址等。
[funcA, funcB]	funcA 内部调用 funcB，funcB 的栈帧被推入栈顶。包含 funcB 的局部变量 b，返回地址（指向 funcA）。
[funcA, funcB, funcC]	funcB 内部调用 funcC，funcC 的栈帧被推入栈顶。包含 funcC 的局部变量 c，返回地址（指向 funcB）。
[funcA, funcB]	funcC 执行完毕，其栈帧被弹出。程序回到 funcB 的返回地址继续执行。
[funcA]	funcB 执行完毕，其栈帧被弹出。程序回到 funcA 的返回地址继续执行。
[global]	funcA 执行完毕，其栈帧被弹出。程序回到全局作用域。

每一次函数调用都会产生一个栈帧，并将其推入栈中。当函数返回时，其对应的栈帧就会从栈中弹出。这个过程对于理解 TCO 至关重要。

---

二、尾调用及其优化原理

2.1 什么是尾调用？

一个函数调用是“尾调用”当且仅当它是当前函数执行的最后一个操作，并且其返回值直接作为当前函数的返回值。这意味着在尾调用之后，当前函数不会再执行任何其他操作（包括表达式计算、变量赋值等）。

让我们看一些例子：

是尾调用：

function foo(x) {
  // 这是尾调用，foo 的返回值直接是 bar(x) 的返回值
  return bar(x);
}

function factorialTailRecursive(n, acc = 1) {
  if (n === 0) {
    return acc;
  }
  // 这是尾调用，factorialTailRecursive 的返回值直接是自身的递归调用结果
  return factorialTailRecursive(n - 1, n * acc);
}

不是尾调用：

function foo(x) {
  // 不是尾调用，因为 bar(x) 的结果还需要与 1 相加
  return bar(x) + 1;
}

function baz(x) {
  // 不是尾调用，因为 bar(x) 的结果还需要赋给变量 y
  let y = bar(x);
  return y;
}

function qux(x) {
  bar(x);
  // 不是尾调用，虽然 bar(x) 是最后执行的函数，但它的返回值没有被 qux 返回
  // qux 隐式返回 undefined
}

function anotherFactorial(n) {
  if (n === 0) {
    return 1;
  }
  // 不是尾调用，因为 n * (factorial(n - 1))，乘法操作在递归调用之后
  return n * anotherFactorial(n - 1);
}

识别尾调用是 TCO 的第一步。

2.2 尾调用优化（TCO）的原理

当一个函数执行尾调用时，传统的处理方式是为被调用的函数创建一个新的栈帧。而 TCO 的原理则不同：

1. 复用栈帧：由于当前函数在尾调用之后不再需要其栈帧（因为它不会再执行任何操作，也不需要其局部变量或参数），解释器/编译器可以直接复用当前函数的栈帧来执行被尾调用的函数。
2. 更新栈帧信息：将当前栈帧的返回地址更新为调用当前函数的那个函数的返回地址，更新参数和局部变量区域为被尾调用的函数的参数和局部变量。
3. 不创建新栈帧：这样，被尾调用的函数就不会在栈上创建新的栈帧，而是直接在原地“跳转”执行。

通过这种方式，无论递归调用多少次，调用栈的高度都不会增加，始终保持在一个固定的深度。这就将递归转换成了效率等同于迭代的执行模式，从而避免了栈溢出。

以 factorialTailRecursive 为例，如果启用了 TCO：

function factorialTailRecursive(n, acc = 1) {
  if (n === 0) {
    return acc;
  }
  return factorialTailRecursive(n - 1, n * acc);
}

// 假设调用 factorialTailRecursive(3, 1)

// 传统调用栈：
// [global]
// [factorialTailRecursive(3, 1)]
// [factorialTailRecursive(3, 1), factorialTailRecursive(2, 3)]
// [factorialTailRecursive(3, 1), factorialTailRecursive(2, 3), factorialTailRecursive(1, 6)]
// [factorialTailRecursive(3, 1), factorialTailRecursive(2, 3), factorialTailRecursive(1, 6), factorialTailRecursive(0, 6)] // n=0, return 6
// ... 依次弹出栈帧

// 启用 TCO 后的调用栈：
// 初始调用：factorialTailRecursive(3, 1)
// 栈帧: { n: 3, acc: 1, return_addr: <caller_of_factorial> }

// 尾调用 factorialTailRecursive(2, 3)
// 复用当前栈帧，更新其内容：
// 栈帧: { n: 2, acc: 3, return_addr: <caller_of_factorial> } (注意返回地址不变)

// 尾调用 factorialTailRecursive(1, 6)
// 复用当前栈帧，更新其内容：
// 栈帧: { n: 1, acc: 6, return_addr: <caller_of_factorial> }

// 尾调用 factorialTailRecursive(0, 6)
// 复用当前栈帧，更新其内容：
// 栈帧: { n: 0, acc: 6, return_addr: <caller_of_factorial> }

// n === 0, 返回 acc (6)。栈帧弹出。
// 栈高度始终保持为 1。

可见，TCO 是一种非常高效且优雅的优化。那么，为何 JavaScript 迟迟不能普遍支持它呢？

---

三、JavaScript 中的词法环境（Lexical Environment）深度解析

要理解 TCO 在 JavaScript 中遇到的挑战，我们必须首先深入理解 JavaScript 的核心概念之一：词法环境（Lexical Environment）。

3.1 什么是词法环境？

词法环境是 ECMAScript 规范中定义的一种抽象机制，用于管理标识符（变量名、函数名等）与它们对应值之间的映射关系，也就是我们常说的“作用域”。简单来说，它决定了在代码的某个特定位置，哪些变量是可访问的，以及它们的值是什么。

每个执行上下文（Execution Context），例如全局执行上下文、函数执行上下文等，都有一个与之关联的词法环境。

一个词法环境主要包含两个组件：

1. 环境记录器（Environment Record）：一个实际存储变量和函数声明的地方。它是一个映射表，将标识符绑定到它们的值上。
   • 声明式环境记录器（Declarative Environment Record）：用于存储 var, let, const, function 声明。
   • 对象式环境记录器（Object Environment Record）：用于 with 语句和全局环境，将属性绑定到对象上。
2. 外部词法环境引用（Outer Lexical Environment Reference）：指向外部（ enclosing ）词法环境的引用。这个引用是形成作用域链的关键。

3.2 词法环境的创建与作用域链

当一个函数被定义时，它会“记住”其被创建时的词法环境。这个记住的环境就是该函数的 [[Environment]] 内部槽（或称作 scope 属性，尽管这不是开发者直接访问的）。

当函数被调用时，会创建一个新的函数执行上下文。这个执行上下文会创建一个新的词法环境，其外部词法环境引用会指向函数定义时记住的那个 [[Environment]]。

通过这个外部词法环境引用，JavaScript 引擎能够构建一个“作用域链”（Scope Chain）。当在当前词法环境中找不到某个变量时，引擎会沿着作用域链向上查找，直到找到该变量或到达全局环境。

例如：

let globalVar = 'I am global';

function outerFunc() {
  let outerVar = 'I am outer';

  function innerFunc() {
    let innerVar = 'I am inner';
    console.log(innerVar); // 访问 innerFunc 自己的词法环境
    console.log(outerVar); // 沿着作用域链访问 outerFunc 的词法环境
    console.log(globalVar); // 沿着作用域链访问全局词法环境
  }

  return innerFunc;
}

const myInnerFunc = outerFunc();
myInnerFunc();
// 输出：
// I am inner
// I am outer
// I am global

在这个例子中：

• global 环境有一个 globalVar。
• outerFunc 被调用时，创建一个新的词法环境 LE_outer。LE_outer 包含 outerVar，并且其 Outer 指向 global 词法环境。
• innerFunc 在 outerFunc 内部定义，所以它记住的 [[Environment]] 是 LE_outer。
• 当 myInnerFunc()（即 innerFunc）被调用时，它创建一个新的词法环境 LE_inner。LE_inner 包含 innerVar，并且其 Outer 指向 LE_outer。

作用域链形成了 LE_inner -> LE_outer -> global 这样的查找路径。

3.3 闭包（Closures）与词法环境的生命周期

词法环境最强大的特性之一是它与闭包（Closures）的紧密结合。当一个内部函数引用了其外部函数作用域中的变量，并且该内部函数在外部函数执行完毕后仍然能够被访问时，就形成了闭包。

闭包的实现依赖于词法环境的持久性。即使外部函数的栈帧已经从调用栈中弹出（即外部函数执行完毕），其对应的词法环境也可能不会被垃圾回收，因为它仍然被内部函数所引用。

function makeCounter() {
  let count = 0; // count 变量属于 makeCounter 的词法环境

  return function increment() {
    // increment 是一个闭包，它引用了 count
    count++;
    console.log(count);
  };
}

const counter1 = makeCounter(); // makeCounter 执行完毕，但其词法环境仍被 increment 引用
counter1(); // 1
counter1(); // 2

const counter2 = makeCounter(); // 再次调用 makeCounter，创建了新的词法环境和新的 count
counter2(); // 1

在这个例子中，makeCounter 函数执行完毕后，它的栈帧会被弹出。但是，其内部的 count 变量所在的词法环境并不会立即被垃圾回收，因为它被 increment 函数（即 counter1）的 [[Environment]] 引用着。只要 counter1 存在，count 变量就能够被访问和修改。

这个特性是 JavaScript 强大和灵活性的基石，但它也正是尾调用优化在 JavaScript 中面临挑战的症结所在。

---

四、词法环境对尾调用优化的核心限制

现在，我们将问题聚焦到核心：词法环境如何限制了 TCO 在 JavaScript 中的应用？

TCO 的基本思想是：当一个函数 A 尾调用函数 B 时，函数 A 的栈帧可以被函数 B 复用。这意味着 A 的栈帧及其内部存储的所有信息（包括局部变量、参数、以及它所关联的词法环境）都将被“替换”或“丢弃”，为 B 服务。

问题就出在这里：如果 A 的栈帧被复用，那么 A 的词法环境会发生什么？

4.1 冲突场景一：闭包的“逃逸”问题

假设 JavaScript 引擎无条件地对所有尾调用进行优化。

考虑以下场景：

function createRecursiveClosure(n, acc = []) {
  if (n === 0) {
    return acc;
  }

  let localVal = n * 10; // 局部变量，属于当前 createRecursiveClosure 的词法环境
  // 模拟一个闭包，它捕获了 localVal
  let getLocalVal = function() {
    return localVal;
  };

  acc.push(getLocalVal); // 将闭包函数添加到累积数组中

  // 这是一个尾调用
  return createRecursiveClosure(n - 1, acc);
}

const closures = createRecursiveClosure(3);

// 此时，createRecursiveClosure(3) 的栈帧已经弹出（或被复用）
// createRecursiveClosure(2) 的栈帧已经弹出（或被复用）
// createRecursiveClosure(1) 的栈帧已经弹出（或被复用）

console.log(closures.length); // 3
console.log(closures[0]()); // 期望是 30
console.log(closures[1]()); // 期望是 20
console.log(closures[2]()); // 期望是 10

如果 createRecursiveClosure 函数的尾调用被优化，那么在每次递归调用时，当前的栈帧都会被复用。这意味着：

1. 当 createRecursiveClosure(3, []) 调用 createRecursiveClosure(2, [...]) 时，createRecursiveClosure(3) 的栈帧会被 createRecursiveClosure(2) 复用。
2. 当 createRecursiveClosure(2, [...]) 调用 createRecursiveClosure(1, [...]) 时，createRecursiveClosure(2) 的栈帧会被 createRecursiveClosure(1) 复用。
3. 以此类推。

致命的问题在于：

如果 createRecursiveClosure(N) 的栈帧被复用（即被“销毁”并替换），那么其内部的 localVal 变量（以及整个 createRecursiveClosure(N) 的词法环境）在理论上就应该被销毁或变得不可访问。然而，我们通过 acc.push(getLocalVal) 将一个闭包 getLocalVal 推入了数组并返回。这个闭包明确地捕获了 localVal 变量。

• 如果没有 TCO：每个 createRecursiveClosure 调用都有其独立的栈帧和词法环境。当 createRecursiveClosure(3) 返回时，它的栈帧被弹出，但因为 getLocalVal 闭包的存在，其词法环境会被保留，closures[0]() 仍然可以正确访问到 localVal (30)。
• 如果启用了 TCO：当 createRecursiveClosure(3) 的栈帧被 createRecursiveClosure(2) 复用时，createRecursiveClosure(3) 的词法环境理论上就应该被释放。那么，当 closures[0]() 尝试访问它捕获的 localVal 时，它将无法找到正确的值，甚至可能导致程序崩溃或访问到错误的数据。

这直接违反了 JavaScript 闭包的语义：闭包应该能够始终访问到它们被创建时所处作用域的变量，无论外部函数是否已经返回。 尾调用优化会改变这种“可观察到的行为”（Observable Behavior），这是 ECMAScript 规范所不允许的。

4.2 TCO 与词法环境生命周期的分离

核心问题在于，在 JavaScript 中，一个函数的词法环境的生命周期不一定与其栈帧的生命周期绑定。

• 栈帧：与函数的实际执行过程相关联，当函数返回时通常被销毁。
• 词法环境：与变量的可见性和生命周期相关联，只要有任何闭包或其他实体引用它，即使对应的栈帧已经消失，词法环境也必须保持活跃。

TCO 强制将栈帧“销毁”或“重写”，这隐含地也释放了其所关联的词法环境。如果这个词法环境被某个“逃逸”的闭包所引用，那么 TCO 就会破坏闭包的语义。

4.3 调试体验的冲击

除了语义上的冲突，TCO 还会对调试体验产生负面影响。当启用 TCO 时，调用栈的深度会大幅度缩减。这意味着：

• 更短的堆栈跟踪（Stack Traces）：当程序出错时，堆栈跟踪是定位问题的重要工具。TCO 会使得递归调用的堆栈跟踪变得非常短，因为中间的栈帧都被复用了。这会极大地增加调试的难度，让开发者难以追踪递归的调用路径。
• 断点行为异常：在被 TCO 优化的代码中设置断点，可能会发现断点在逻辑上“跳跃”执行，或者无法按预期捕获到每一次递归调用。

这些都是在语言设计层面需要慎重考虑的因素，尤其对于像 JavaScript 这样注重开发者体验和强大调试能力的语言。

---

五、ECMAScript 标准委员会的考量与历史

JavaScript 社区和 ECMAScript 标准委员会（TC39）对尾调用优化并非不闻不问。事实上，在 ES6（ECMAScript 2015）的初期规范中，是明确包含了对尾调用优化的支持的，并且要求在“严格模式”（'use strict'）下强制执行。

5.1 ES6 的尝试：严格模式下的尾调用优化

最初的想法是，在严格模式下，开发者明确表示愿意接受一些行为上的变化，以换取更好的性能和特性。因此，TCO 被提议作为严格模式的一个特性，以避免影响现有非严格模式代码的行为。

然而，在实际实现和讨论过程中，以下问题变得越来越突出：

1. “可观察到的行为”问题：如前所述，即使在严格模式下，TCO 也会改变闭包的语义和堆栈跟踪，这被认为是语言核心行为的改变，而不仅仅是性能优化。这种行为的改变被认为过于激进，且难以向开发者解释清楚。
2. 实现复杂性与不一致性：如何在各种复杂场景下（特别是涉及 eval、arguments 对象、try...finally 块等）正确地识别和优化尾调用，同时又不破坏闭包语义，对引擎实现者来说是一个巨大的挑战。不同的 JavaScript 引擎（如 V8、SpiderMonkey、JavaScriptCore）对 TCO 的实现方式和支持程度可能不一致，导致代码在不同环境中表现不同，这违背了 JavaScript 跨平台一致性的原则。
3. 调试工具的兼容性：当时的调试工具链还没有准备好处理 TCO 带来的堆栈跟踪变化。

5.2 最终的降级与现状

鉴于上述问题，TC39 委员会最终在 ES6 发布后，决定将强制性的尾调用优化从规范中移除。它被降级为一个“附录”级别的可选优化，这意味着引擎可以根据自己的情况选择性地实现它，但开发者不能依赖它的存在。

目前，绝大多数主流 JavaScript 引擎（如 V8/Chrome, JavaScriptCore/Safari）都没有实现或默认启用标准的尾调用优化。Firefox 的 SpiderMonkey 引擎曾经在早期版本中实现过有限的 TCO，但由于与其他引擎的不兼容性以及上述的调试问题，后来也取消了强制性的 TCO。

因此，在现代 JavaScript 中，开发者不能指望 TCO 会自动优化他们的递归代码。 如果需要处理深度递归，必须采取其他策略。

---

六、尾调用优化的替代方案

既然 JavaScript 引擎不提供通用的尾调用优化，那么当我们需要处理深度递归时，有哪些替代方案可以避免栈溢出呢？

6.1 A. 迭代（Iterative）重构

最直接、最推荐的方法是将递归算法重构为迭代算法（使用 for、while 循环）。这通常是最性能优越且最安全的方案。

原始递归 (非尾递归):

function factorialRecursive(n) {
  if (n === 0) {
    return 1;
  }
  return n * factorialRecursive(n - 1);
}

尾递归形式 (如果 TCO 存在):

function factorialTailRecursive(n, acc = 1) {
  if (n === 0) {
    return acc;
  }
  return factorialTailRecursive(n - 1, n * acc);
}

迭代形式 (推荐):

function factorialIterative(n) {
  let acc = 1;
  for (let i = n; i > 0; i--) {
    acc *= i;
  }
  return acc;
}

// console.log(factorialIterative(10000)); // 正常运行

优点：

• 完全避免栈溢出。
• 通常性能最佳，因为没有函数调用的开销。
• 代码更易于理解和调试（对某些问题而言）。

缺点：

• 对于某些复杂的递归问题，将其转换为迭代形式可能比较困难，甚至导致代码可读性下降。

6.2 B. 蹦床函数（Trampolining）

蹦床函数是一种将递归调用“扁平化”为迭代调用的模式，从而避免栈溢出。其核心思想是，被递归调用的函数不直接返回结果，而是返回一个特殊的“thunk”（一个返回另一个函数或最终结果的函数）。一个“蹦床”函数会不断地调用这些 thunk，直到得到最终结果。

Thunk 示例：

function thunk(fn, ...args) {
  return function() {
    return fn(...args);
  };
}

蹦床函数实现：

function trampoline(f) {
  while (typeof f === 'function') {
    f = f();
  }
  return f;
}

将尾递归函数改造为蹦床模式：

function sumTailRecursive(n, acc = 0) {
  if (n === 0) {
    return acc; // 返回最终结果
  }
  // 不直接调用，而是返回一个 thunk
  return thunk(sumTailRecursive, n - 1, acc + n);
}

// 使用 trampoline 执行：
// console.log(trampoline(thunk(sumTailRecursive, 100000, 0))); // 正常运行

工作原理：

1. trampoline 函数接收一个函数 f（这里是 thunk(sumTailRecursive, 100000, 0)）。
2. while 循环检查 f 是否是一个函数。如果是，它就执行 f()。
3. f() 的执行会返回一个新的 thunk（如果递归还没结束）或最终结果。
4. 循环继续，直到 f 不再是函数（即 sumTailRecursive 返回了最终的数值 acc）。
5. 最终 trampoline 返回这个数值。

优点：

• 保留了递归的结构和表达力。
• 有效避免栈溢出。

缺点：

• 引入了额外的复杂性（需要编写 thunk 和 trampoline 函数）。
• 性能开销比纯迭代方案高，因为每次递归步骤都需要创建并调用一个新的 thunk 函数。
• 调试可能变得更加复杂。

6.3 C. 异步递归 / Promise 链 (针对特定异步场景)

对于一些涉及异步操作的深度递归，可以通过将递归步骤拆分成异步任务，并使用 Promise 链或 async/await 来避免同步栈的深度。这通常不是为了优化纯计算递归，而是为了处理如遍历深度嵌套数据结构时的 I/O 操作。

// 假设有一个异步的 processItem 函数
function processItemAsync(item) {
  return new Promise(resolve => {
    setTimeout(() => {
      console.log(`Processing ${item}`);
      resolve(item + 1);
    }, 0);
  });
}

async function recursiveAsyncProcess(n) {
  if (n === 0) {
    return 0;
  }
  const processedVal = await processItemAsync(n);
  // 这里 await 使得当前函数挂起，栈帧会被弹出，
  // 下一次递归调用在事件循环的下一个 tick 执行
  return recursiveAsyncProcess(n - 1);
}

// recursiveAsyncProcess(1000); // 不会栈溢出，但也不是传统意义上的 TCO

这种方案并不能直接替代同步计算的 TCO，但它提供了一种在异步场景下处理深度“递归”的方法，其核心在于将任务分解到事件循环的不同阶段，从而避免单一调用栈的过度增长。

---

七、尾调用优化的未来与开发者策略

我们深入探讨了 JavaScript 中尾调用优化的缺失及其背后的深层原因：词法环境与闭包机制的语义保证与 TCO 栈帧复用之间的固有冲突。TC39 委员会在权衡了性能提升、语言语义一致性、调试体验以及引擎实现复杂性之后，做出了一个务实的决策——不强制要求 TCO。

这意味着，作为 JavaScript 开发者，我们不能指望语言运行时会为我们自动优化尾递归。当面对可能导致栈溢出的深度递归场景时，我们必须主动采取措施。最稳妥且推荐的做法仍然是将递归重构为迭代形式。对于那些难以迭代化或希望保留函数式递归表达力的场景，蹦床函数提供了一个可行的折衷方案。

JavaScript 语言的设计哲学之一是提供一致且可预测的行为。在尾调用优化这一点上，委员会选择了维护语言的核心语义和开发者体验，而非仅仅追求性能的极致。这是一个艰难但可以理解的权衡，它也提醒我们，理解语言的底层机制对于编写健壮、高效的代码至关重要。