JavaScript 中的尾调用优化（TCO）：ES6 规范要求与 V8 的实现状态

各位同仁，大家好！今天我们将深入探讨一个在 JavaScript 社区中长期存在，且充满争议的话题：尾调用优化（Tail Call Optimization，简称 TCO）。它不仅关乎代码的性能，更触及我们如何编写健壮、可扩展的函数式代码的深层原理。我们将从基础概念讲起，逐步剖析 ES6 规范对 TCO 的要求，以及 V8 引擎在实践中的真实状态，最后探讨在缺乏通用 TCO 的环境下，我们有哪些可行的替代方案。

1. 为什么需要尾调用优化？理解函数调用栈

在深入 TCO 之前，我们必须先理解函数在 JavaScript 引擎内部是如何被调用的，以及调用栈（Call Stack）扮演的角色。每次我们调用一个函数，JavaScript 引擎都会创建一个新的“栈帧”（Stack Frame）并将其推入调用栈。这个栈帧包含了函数执行所需的所有信息，例如：

• 返回地址：函数执行完毕后，程序应该回到哪里继续执行。
• 函数参数：传递给函数的参数值。
• 局部变量：函数内部声明的局部变量。
• 当前上下文：this 的值。

当函数执行完毕并返回时，其对应的栈帧就会从调用栈中弹出。这个过程简单而高效，但当函数调用层级过深时，问题就浮现了。

考虑一个简单的递归函数，用于计算阶乘：

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

console.log(factorial(5)); // 120
// console.log(factorial(10000)); // 可能会导致栈溢出

当我们调用 factorial(5) 时，调用栈的变化大致如下：

1. [factorial(5)]
2. [factorial(4), factorial(5)]
3. [factorial(3), factorial(4), factorial(5)]
4. [factorial(2), factorial(3), factorial(4), factorial(5)]
5. [factorial(1), factorial(2), factorial(3), factorial(4), factorial(5)]
6. [factorial(0), factorial(1), factorial(2), factorial(3), factorial(4), factorial(5)]

当 factorial(0) 返回 1 时，栈帧开始依次弹出，计算结果：

1. factorial(0) 返回 1
2. factorial(1) 计算 1 * 1 = 1，返回 1
3. factorial(2) 计算 2 * 1 = 2，返回 2
4. factorial(3) 计算 3 * 2 = 6，返回 6
5. factorial(4) 计算 4 * 6 = 24，返回 24
6. factorial(5) 计算 5 * 24 = 120，返回 120

在这个过程中，每个 factorial 调用的栈帧都必须保留在栈中，直到它依赖的下一个 factorial 调用返回结果。如果 n 的值非常大，比如 10000，那么调用栈会变得非常深，最终耗尽内存，导致我们熟悉的“栈溢出”（Stack Overflow）错误。

栈溢出不仅是一个错误，它也限制了我们使用递归解决问题的能力，尤其是在函数式编程范式中，递归是一种非常自然和强大的工具。TCO 的核心目标就是解决这一问题。

2. 什么是尾调用？

尾调用（Tail Call）是指一个函数在执行的最后一步调用另一个函数（或者它自己）。这里的“最后一步”是关键。如果一个函数在调用另一个函数后，还需要对返回结果进行任何操作，那么它就不是尾调用。

我们来看一些例子来区分：

非尾调用示例：

// 示例 1: 返回值需要进行乘法操作
function multiply(a, b) {
  return a * b;
}

function caller1(x, y) {
  // 在调用 multiply(x, y) 后，还需要执行乘法操作
  return multiply(x, y) + 1;
}

// 示例 2: 在调用后有其他语句
function caller2(x, y) {
  const result = multiply(x, y);
  console.log("Called multiply"); // 这一行使得它不是尾调用
  return result;
}

// 示例 3: 即使是返回自身，如果返回后还有操作，也不是尾调用
function nonTailRecursiveFactorial(n, acc = 1) {
  if (n === 0) {
    return acc;
  }
  // n * ... 表示在递归调用返回后，还需要执行乘法操作
  return n * nonTailRecursiveFactorial(n - 1, acc);
}

在上述 caller1 和 nonTailRecursiveFactorial 中，multiply(x, y) 和 nonTailRecursiveFactorial(n - 1, acc) 的调用都不是尾调用，因为它们的结果还需要被 + 1 或 n * 进一步处理。在 caller2 中，console.log 的存在使得 multiply 的调用不是最后一步。

尾调用示例：

// 示例 1: 直接返回另一个函数调用的结果
function add(a, b) {
  return a + b;
}

function caller3(x, y) {
  // 调用 add(x, y) 是函数执行的最后一步，其结果直接作为 caller3 的返回值
  return add(x, y);
}

// 示例 2: 尾递归 - 尾调用自身
// 这是一个“尾递归”函数，它在尾位置调用自身
function tailRecursiveFactorial(n, acc = 1) {
  if (n === 0) {
    return acc;
  }
  // 递归调用 tailRecursiveFactorial(n - 1, acc * n) 是函数执行的最后一步
  // 它的返回值直接作为当前函数的返回值，没有任何后续操作
  return tailRecursiveFactorial(n - 1, acc * n);
}

// 示例 3: 更复杂的尾调用判断
function funcA(a) {
  if (a > 0) {
    return funcB(a - 1); // 尾调用
  } else {
    return funcC(a); // 尾调用
  }
}

function funcB(b) {
  return funcD(b * 2); // 尾调用
}

function funcC(c) {
  return c + 1; // 不是尾调用，因为它返回一个字面量或表达式结果，而不是函数调用的结果
}

function funcD(d) {
  return d; // 同上，不是尾调用
}

在 tailRecursiveFactorial 中，tailRecursiveFactorial(n - 1, acc * n) 是一个尾调用。当 tailRecursiveFactorial 调用自身时，它不再需要自己的栈帧。它可以直接复用当前栈帧，并将新的参数和局部变量设置好，然后“跳转”到被调用的函数开始执行，而不需要在调用栈中添加新的帧。这就是尾调用优化的核心思想。

3. 尾调用优化（TCO）的原理

尾调用优化的原理在于，当一个函数 A 进行尾调用，调用函数 B 时，函数 A 在调用 B 之后不再需要执行任何操作。这意味着 A 的栈帧在调用 B 之前就已经完成了它的使命。因此，JavaScript 引擎可以：

1. 清空或复用函数 A 的当前栈帧：将 A 的参数和局部变量替换为 B 的参数和局部变量。
2. 直接跳转到函数 B 的入口点：而不是创建一个新的栈帧。

通过这种方式，原本会不断增长的调用栈，在发生尾调用时可以保持恒定大小。对于递归调用，特别是尾递归，这意味着无限深的递归调用也不会导致栈溢出。

让我们用 tailRecursiveFactorial 的例子来形象化 TCO 的过程：

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

假设我们调用 tailRecursiveFactorial(5)：

无 TCO 的调用栈（回顾）：

1. [tailRecursiveFactorial(5, 1)]
2. [tailRecursiveFactorial(4, 5), tailRecursiveFactorial(5, 1)]
3. [tailRecursiveFactorial(3, 20), tailRecursiveFactorial(4, 5), tailRecursiveFactorial(5, 1)]
4. … 栈帧不断增加

有 TCO 的调用栈（理想状态）：

1. 初始调用：tailRecursiveFactorial(5, 1)。栈：[frame_A]
2. 函数体执行，判断 n !== 0。准备尾调用 tailRecursiveFactorial(4, 5)。
3. 引擎识别为尾调用，复用 frame_A。更新 frame_A 的参数为 n=4, acc=5。跳转到 tailRecursiveFactorial 的开头。栈：[frame_A]
4. 函数体执行，判断 n !== 0。准备尾调用 tailRecursiveFactorial(3, 20)。
5. 引擎识别为尾调用，复用 frame_A。更新 frame_A 的参数为 n=3, acc=20。跳转到 tailRecursiveFactorial 的开头。栈：[frame_A]
6. … 这个过程重复，直到 n === 0。
7. 当 n === 0 时，返回 acc（即 120）。

整个过程中，调用栈的深度始终保持为 1（即只有一个 tailRecursiveFactorial 的栈帧）。这有效地消除了栈溢出的风险，并且由于避免了创建和销毁栈帧的开销，理论上也能带来性能提升。

TCO 的主要好处：

• 消除栈溢出：允许使用深度递归而无需担心栈空间限制。
• 性能提升：减少了栈帧的创建和销毁操作。
• 支持函数式编程范式：使递归成为处理迭代任务的有效且安全的工具，尤其是在高阶函数和不可变数据结构结合使用时。

4. ES6 规范对 TCO 的要求：期望与现实

在 ES2015 (ES6) 发布之前，JavaScript 社区对 TCO 的支持呼声很高。许多其他函数式编程语言，如 Scheme、OCaml 等，都原生支持 TCO。开发者们希望 JavaScript 也能提供这项重要的优化。

ES6 规范的初衷：强制要求 TCO

ES6 规范草案最初确实包含了强制性的 TCO 要求。这意味着任何符合 ES6 规范的 JavaScript 引擎都必须实现 TCO。这一决策背后的理念是：

1. 标准化行为：确保开发者可以依赖 TCO 编写深度递归代码，而无需担心在不同引擎上的行为差异。
2. 推动函数式编程：TCO 是函数式编程中递归模式的关键基础设施。
3. 解决栈溢出问题：提供一种语言层面的机制来规避深度递归的栈限制。

规范中明确了哪些调用属于“可优化的尾调用位置”（optimizable tail call positions），并要求引擎在这些位置上进行优化。例如，规范中对于 return CallExpression; 这样的语句，如果 CallExpression 是一个函数调用，且该函数调用的结果直接被返回，那么这就是一个尾调用位置。

为什么 ES6 最终放弃了强制要求 TCO？

尽管初衷良好，但随着 ES6 规范的推进和引擎实现者的反馈，强制性 TCO 的要求最终被撤销了。这是一个重大且充满争议的决定，主要原因包括：

1. 调试器兼容性问题：这是最主要的原因。当 TCO 发生时，被优化的栈帧被移除或复用，这意味着在调试器中查看调用栈时，会丢失中间的调用记录。这使得调试深度递归函数变得异常困难，因为你无法看到完整的调用链条。对于开发者而言，调试能力的重要性往往高于性能或栈深度。

   • 示例：

     function f(n) {
       if (n === 0) return 0;
       return g(n - 1); // 假设这里发生 TCO
     }
     
     function g(n) {
       if (n === 0) return 0;
       return f(n - 1); // 假设这里发生 TCO
     }
     
     // 假设 f(100) -> g(99) -> f(98) ... -> g(1) -> f(0)
     // 如果在 f(0) 处设置断点，调试器可能只能显示当前的 f(0) 栈帧，而无法回溯到 f(100)
     // 这对于理解程序流程和定位错误是灾难性的。

2. 与现有引擎的复杂性：实现 TCO 并非易事，特别是在现有的大型、高度优化的 JavaScript 引擎（如 V8、SpiderMonkey、JavaScriptCore）中。这些引擎的优化器已经非常复杂，引入 TCO 需要对底层架构进行重大修改，这可能引入新的性能问题或稳定性风险。

3. 性能权衡：虽然 TCO 理论上可以提升性能，但在某些情况下，实现 TCO 可能需要额外的检查和逻辑，反而会增加运行时开销。引擎开发者需要仔细权衡这些得失。

4. 互操作性问题：JavaScript 经常与其他语言（如 C++、WebAssembly）进行交互。TCO 可能会改变调用栈的结构，使得这些跨语言调用的栈帧管理变得更加复杂。

由于这些实际的技术挑战，以及调试器开发者和引擎开发者社区的强烈反对，TC39（ECMAScript 标准化委员会）最终在 ES2016 (ES7) 中决定将 TCO 从强制性要求降级为“未指定”（unspecified）行为。这意味着引擎可以选择实现 TCO，也可以不实现，开发者不应该依赖它的存在。

ES6 规范的当前状态：TCO 是可选的

当前 ES 规范中关于 TCO 的状态是：引擎可以实现尾调用优化，但不是强制性的。这意味着，开发者在编写 JavaScript 代码时，不应该假设 TCO 会发生。如果你的代码依赖 TCO 来避免栈溢出，那么它在大多数现代 JavaScript 运行时中都可能失败。

这一决定让许多函数式编程爱好者感到失望，但它反映了标准委员会在理想与实际实现复杂性之间做出的艰难权衡。

5. V8 引擎的实现状态：一个未兑现的承诺

V8 是 Google Chrome 和 Node.js 所使用的 JavaScript 引擎，其性能和优化能力一直处于领先地位。对于 TCO，V8 引擎的历史和现状非常能体现 ES6 规范的这一争议。

V8 对 TCO 的历史态度

在 ES6 规范初稿要求强制 TCO 的时期，V8 团队也曾尝试实现 TCO。在早期的 Chrome 和 Node.js 版本中，可以通过一个 --harmony-tailcalls 的运行时标志来启用实验性的 TCO。然而，这个实验性的实现从未达到生产级别，并且很快就被移除了，因为遇到了与调试器兼容性、性能权衡以及实现复杂性相关的问题。

V8 为什么没有实现通用的 TCO？

V8 引擎没有实现通用的、ECMAScript 规范所设想的 TCO，其原因与 TC39 放弃强制 TCO 的原因高度一致：

1. 调试器支持：这是 V8 团队最看重的方面之一。V8 团队强调，如果 TCO 导致调用栈信息丢失，那么对于开发者而言，调试体验会变得非常糟糕。V8 的设计哲学是提供最佳的开发者体验，而调试是其中的核心组成部分。

2. 性能与复杂性：V8 拥有非常先进的 JIT (Just-In-Time) 编译器，如 TurboFan。实现 TCO 需要在 JIT 编译器的多个阶段进行深度集成，并确保它不会与现有的其他优化（如内联、循环优化等）发生冲突，或引入新的性能瓶颈。维护和发展这样一个复杂的系统，同时还要支持 TCO，成本非常高。

3. 替代方案的存在：V8 团队认为，对于大多数需要深度递归的场景，开发者可以通过迭代（循环）或使用蹦床函数等模式来规避栈溢出问题，而无需语言层面提供强制性的 TCO。

V8 对尾调用的特定优化：自尾调用转循环

尽管 V8 不支持通用的 TCO，但它在某些特定情况下会进行优化，尤其是针对自尾调用（Self-Tail Call），即函数在尾位置调用自身。V8 的 JIT 编译器可能会将某些形式的尾递归函数识别并转换为等效的循环结构。

这种优化被称为尾调用消除（Tail Call Elimination），它本质上是将递归转化为迭代。例如，对于 tailRecursiveFactorial 这样的函数：

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

V8 编译器可能会将其内部转换为类似以下的迭代形式：

// V8 内部可能会进行的优化，并非实际执行的 JS 代码
function tailRecursiveFactorialOptimized(n, acc = 1) {
  while (true) { // 模拟循环
    if (n === 0) {
      return acc;
    }
    // 更新参数，模拟递归调用的新状态
    acc = acc * n;
    n = n - 1;
    // 再次循环，而不是创建新的栈帧
  }
}

这种“尾递归转循环”的优化，可以在不丢失调试信息（因为整个函数仍然在一个栈帧中执行，只是内部逻辑变成了循环）的前提下，解决栈溢出问题。然而，这种优化是启发式的，并非所有自尾调用都会被优化，且仅限于自尾调用。互尾调用（Mutual Tail Calls），即函数 A 尾调用 B，B 尾调用 C，C 尾调用 A 这种循环调用，V8 几乎不进行优化。

V8 的实际行为验证

我们可以通过一个简单的实验来验证 V8（Node.js 或 Chrome）中 TCO 的缺失。

// tail_call_test.js
function tailRecursiveFunc(n, acc = 0) {
  // console.log(`n: ${n}, acc: ${acc}`); // 可以用来观察栈深度
  if (n === 0) {
    return acc;
  }
  // 这是一个尾调用
  return tailRecursiveFunc(n - 1, acc + 1);
}

const MAX_DEPTH = 100000; // 尝试一个足够大的数字

try {
  console.log(`尝试调用 tailRecursiveFunc(${MAX_DEPTH})...`);
  const result = tailRecursiveFunc(MAX_DEPTH);
  console.log(`结果: ${result}`);
  console.log("尾调用优化似乎有效 (或被转换为循环)");
} catch (e) {
  if (e instanceof RangeError && e.message.includes('Maximum call stack size exceeded')) {
    console.error(`错误: 栈溢出！尾调用优化在当前环境中未生效。`);
  } else {
    console.error(`发生未知错误: ${e.message}`);
  }
}

// 非尾调用版本，必然栈溢出
function nonTailRecursiveFunc(n) {
  if (n === 0) {
    return 0;
  }
  // 非尾调用，因为需要对结果 + 1
  return nonTailRecursiveFunc(n - 1) + 1;
}

try {
  console.log(`n尝试调用 nonTailRecursiveFunc(${MAX_DEPTH})...`);
  const result = nonTailRecursiveFunc(MAX_DEPTH);
  console.log(`结果: ${result}`);
} catch (e) {
  if (e instanceof RangeError && e.message.includes('Maximum call stack size exceeded')) {
    console.error(`错误: 栈溢出！这是预期行为，因为不是尾调用。`);
  } else {
    console.error(`发生未知错误: ${e.message}`);
  }
}

在 Node.js (或 Chrome 开发者工具的控制台) 中运行上述代码，你很可能会看到：

• tailRecursiveFunc 会成功执行并返回结果（MAX_DEPTH），而不会栈溢出。这表明 V8 对这种简单的自尾调用进行了优化，将其转换为了循环。
• nonTailRecursiveFunc 会报栈溢出错误，这符合预期。

这个结果可能会让人产生误解，认为 V8 实现了 TCO。但需要明确的是：这仅仅是 V8 的 JIT 编译器对特定模式的自尾递归进行循环转换的优化，而不是通用的、符合 ES6 规范设想的尾调用优化。如果稍微改变一下 tailRecursiveFunc 的结构，例如引入一个非自尾调用，或者更复杂的控制流，这种优化可能就会失效。

总结 V8 的 TCO 状态：

特性	描述
通用 TCO	未实现。V8 不支持 ES6 规范最初设想的通用尾调用优化，即在所有尾调用位置消除栈帧。
自尾调用优化	部分实现。V8 的 JIT 编译器能够识别并优化特定模式的自尾递归（函数在尾位置调用自身），将其转换为等效的循环结构，从而避免栈溢出。这是一种启发式优化，不保证所有自尾调用都能被优化。
互尾调用优化	未实现。V8 不支持函数 A 尾调用 B，B 尾调用 A 这种互递归的优化。
调试器兼容性	V8 团队优先考虑调试器兼容性。通用 TCO 会导致栈信息丢失，因此被拒绝。通过将自尾调用转换为循环，可以保留调试信息。
--harmony-tailcalls	这个实验性标志在 V8 中已经被移除，不再有任何作用。
当前建议	开发者不应依赖 JavaScript 引擎的 TCO。对于深度递归，应优先考虑使用迭代（循环）或显式模拟 TCO 的技术。

6. 缺乏通用 TCO 时的替代方案与最佳实践

鉴于 JavaScript 引擎普遍缺乏通用 TCO，我们不能依赖它来编写深度递归代码。幸运的是，有一些成熟的模式和技术可以帮助我们规避栈溢出问题，同时仍然保持代码的函数式风格或解决递归问题。

6.1 迭代（Iteration）代替递归

最直接、最推荐的方法就是将递归逻辑转换为迭代（使用 for 或 while 循环）。现代 JavaScript 引擎对循环的优化非常成熟和高效。

// 原始尾递归阶乘
function tailRecursiveFactorial(n, acc = 1) {
  if (n === 0) {
    return acc;
  }
  return tailRecursiveFactorial(n - 1, acc * n);
}

// 迭代版本阶乘
function iterativeFactorial(n) {
  let acc = 1;
  for (let i = n; i > 0; i--) {
    acc *= i;
  }
  return acc;
}

console.log(iterativeFactorial(5)); // 120
console.log(iterativeFactorial(10000)); // 成功计算，不会栈溢出

对于很多递归问题，都可以找到一个等价的迭代解法。这通常是最高效和最安全的方式。

6.2 蹦床函数（Trampolines）

蹦床函数是一种模拟 TCO 的技术，它通过将递归函数的调用结果包装在一个特殊的“thunk”（一个返回函数的函数）中，然后由一个循环来执行这些 thunk，直到得到最终结果。这样，每次递归调用都不会直接创建新的栈帧，而是返回一个待执行的函数，然后由蹦床函数在循环中调度执行。

基本思想：

1. 递归函数不再直接返回结果，而是返回一个函数（thunk），这个函数在被调用时会执行下一个递归步骤。
2. 蹦床函数接受这个 thunk，并在一个 while 循环中反复调用它，直到 thunk 返回一个非函数值（即最终结果）。

示例：使用蹦床函数实现斐波那契数列

// 辅助函数：将值或函数包装成一个可执行的 thunk
function trampoline(f) {
  return function(...args) {
    let result = f(...args);
    while (typeof result === 'function') {
      result = result();
    }
    return result;
  };
}

// 递归函数，返回 thunk
function fibonacciRecursive(n, a = 0, b = 1) {
  if (n === 0) {
    return a;
  }
  // 返回一个 thunk，而不是直接调用
  return () => fibonacciRecursive(n - 1, b, a + b);
}

// 使用蹦床函数包装后的斐波那契函数
const fib = trampoline(fibonacciRecursive);

console.log(fib(10));  // 55
// console.log(fib(10000)); // 成功计算，但可能耗时较长
// 注意：即使是蹦床函数，对于非常大的 N，计算时间仍可能是问题，但它不会栈溢出。

蹦床函数的优缺点：

• 优点：
  • 避免栈溢出。
  • 保留了递归的结构，代码逻辑可能更清晰。
• 缺点：
  • 引入了额外的函数调用开销（每次递归步骤都创建并调用一个 thunk）。
  • 代码结构变得稍微复杂。
  • 性能通常不如直接的迭代。

蹦床函数适用于那些递归结构难以直接转换为迭代，或者希望保留函数式风格的场景。

6.3 Continuation-Passing Style (CPS)

Continuation-Passing Style (CPS) 是一种编程风格，其中每个函数都接收一个额外的参数，即“ continuation”（一个回调函数）。函数执行完毕后，不是直接返回结果，而是将结果作为参数传递给 continuation 函数。

CPS 可以与 TCO 结合使用，因为将结果传递给 continuation 往往是一个尾调用。但即使没有 TCO，CPS 也可以帮助管理复杂的异步流程或模拟 TCO。

// 阶乘函数的 CPS 版本
function factorialCPS(n, acc, k) {
  if (n === 0) {
    return k(acc); // 将最终结果传递给 continuation
  }
  // 递归调用自身，并将新的 continuation 传递下去
  // 这是一个尾调用，如果引擎支持 TCO，这里可以优化
  return factorialCPS(n - 1, acc * n, k);
}

// 启动函数
function calculateFactorial(n) {
  return factorialCPS(n, 1, result => result); // 初始 continuation 只是返回结果
}

// 这是一个尾递归，在 V8 中可能会被优化为循环
console.log(calculateFactorial(5)); // 120
// console.log(calculateFactorial(10000)); // 成功计算，不会栈溢出 (因为 V8 的自尾递归优化)

在这个 factorialCPS 例子中，它本质上是一个尾递归，所以 V8 仍然会对其进行循环转换优化。CPS 的真正威力体现在处理更复杂的控制流，例如异步操作或需要显式管理控制权的场景。

6.4 显式栈管理

在极少数情况下，如果递归逻辑非常复杂，难以转换为迭代或蹦床，你也可以通过显式地使用数组来模拟调用栈，从而避免真正的 JavaScript 调用栈溢出。但这通常会使代码变得非常复杂和难以维护，不推荐作为常规做法。

// 模拟栈来计算阶乘
function factorialWithExplicitStack(n) {
  const stack = [{ n: n, acc: 1, state: 'call' }]; // 存储待处理的“栈帧”
  let result = null;

  while (stack.length > 0) {
    const currentFrame = stack[stack.length - 1];

    if (currentFrame.state === 'call') {
      // 模拟递归调用
      if (currentFrame.n === 0) {
        result = currentFrame.acc;
        stack.pop(); // 模拟返回
      } else {
        // 进入下一个“递归”层，将当前帧状态设为等待子结果
        currentFrame.state = 'wait_child_result';
        stack.push({ n: currentFrame.n - 1, acc: currentFrame.acc * currentFrame.n, state: 'call' });
      }
    } else if (currentFrame.state === 'wait_child_result') {
      // 已经从子调用中获取结果，更新当前帧
      // 在这个阶乘例子中，其实不需要子结果来更新，因为都是尾递归形式
      // 对于非尾递归，这里需要用 result 参与计算
      stack.pop(); // 模拟返回
    }
  }
  return result;
}

console.log(factorialWithExplicitStack(5)); // 120
console.log(factorialWithExplicitStack(10000)); // 成功计算

这种方法非常底层，且通常比蹦床函数更复杂，只在特殊情况下才会被考虑。

7. 尾调用优化：未竟之业，但仍可期

JavaScript 中的尾调用优化是一个充满技术挑战和设计哲学权衡的议题。ES6 规范最初的强制要求未能落地，主要是因为调试器兼容性问题和引擎实现复杂性。V8 作为主流引擎，也因此未能实现通用的 TCO，尽管它对特定模式的自尾递归进行了循环转换优化。

这并不意味着 TCO 在 JavaScript 中就此终结。社区仍然有声音呼吁对 TCO 的支持，并且未来的 ECMAScript 版本可能会探索新的方法来引入 TCO，例如通过更严格的模式或新的语法来明确声明 TCO 意图，从而允许引擎在不影响调试器的情况下进行优化。WebAssembly 对尾调用的原生支持也可能在某些场景下为 JavaScript 带来间接的 TCO 效益。

对于当前的 JavaScript 开发者而言，最实际的建议是：不要依赖 TCO。当遇到深度递归问题时，优先考虑将其重构为迭代循环。如果需要保持函数式风格或处理复杂递归，蹦床函数是一个值得考虑的替代方案。理解 TCO 的原理，以及它在不同引擎中的实现状态，能够帮助我们编写更健壮、更高效的 JavaScript 代码。这个话题提醒我们，编程语言的演进是一个不断权衡和妥协的过程，最终目标是为开发者提供最好的工具和体验。