尾调用优化（tco）是js引擎在严格模式下对尾位置调用自动复用栈帧的机制，可将递归空间复杂度降至o(1)，但v8、spidermonkey、javascriptcore等主流引擎截至2026年均未启用，实际不可用；替代方案包括手写循环、蹦床函数或构建时转译。
尾调用优化成立的三个硬性条件
只有同时满足以下三点，代码才具备被优化的语法资格：
- 调用必须位于函数体的尾位置：即该函数调用是整个函数执行流的最后一个操作，之后不能再有赋值、计算、日志输出等任何语句；
-
调用结果必须直接返回：不能参与后续运算，例如
return fn(x) + 1或console.log(fn(x))都会破坏尾调用性质； -
必须启用严格模式：全局或函数作用域内需声明
"use strict"，否则引擎直接忽略 TCO 语义。
为什么尾递归看起来更“高效”？
普通递归如 factorial(n) 每次都要等子调用返回后再做乘法，必须保留当前帧的所有上下文；而尾递归写法 factorial(n, acc) 把中间结果通过参数传递，每次调用后无需回退处理，逻辑上只需一个栈帧就能完成全部计算。
理论上，这能让空间复杂度从 O(n) 降到 O(1)，避免 RangeError: Maximum call stack size exceeded。但关键在于：这只是理论。
主流引擎的真实支持现状（截至2026年中）
ES2015 规范强制要求严格模式下实现 TCO，但所有主流引擎都选择了不启用：
- V8（Chrome / Edge / Node.js）：曾实验性支持，后因调试困难、性能权衡及实际收益有限而彻底移除；
- SpiderMonkey（Firefox）：从未默认启用，也无计划上线；
- JavaScriptCore（Safari）：早期短暂支持过，现已撤回，当前版本不生效。
这意味着：哪怕你写出完全合规的尾递归函数，在任何现代浏览器或 Node 环境中运行，依然会爆栈。
真正可用的替代方案
既然不能依赖引擎，就该主动控制执行模型：
-
手写循环：将尾递归结构平铺为
while循环，最简单、最可靠、零兼容性风险； - 蹦床函数（trampoline）：让递归函数返回下一个待执行的函数，由外层循环驱动，模拟栈帧复用效果；
-
构建时转换：使用 Babel 插件（如
@babel/plugin-transform-tail-recursion）在编译阶段自动重写为循环。
这些方法不靠引擎“偷偷优化”，而是把控制权拿回来——既安全，又可预测。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
