JavaScript尾递归语法合法但无栈优化，因V8（2017年移除）、Firefox（从未启用）、Safari（不稳定）等主流引擎均未实现TCO，严格模式下仍会栈溢出。
JavaScript尾递归在语法上可以写出，但实际运行中无法获得栈空间优化——这是最核心的局限。它不是写法问题，而是所有主流引擎（Chrome、Firefox、Node.js、Safari）都未启用或已移除尾调用优化（TCO）支持。
引擎层面根本不支持TCO
ES2015规范虽将TCO列为严格模式下的“必须实现”特性，但现实是：
- V8（Chrome/Node.js）在2017年主动移除了TCO实现，主因是调试困难（
stack丢帧、断点失效）和性能收益不明确 - Firefox从未稳定启用，实验性支持早已关闭
- Safari行为不稳定，官方文档不保证，且在多数实际场景（如含
await、try/catch、闭包变量）下自动退化 - 所谓“严格模式+尾位置”只是规范要求，不是运行保障；写了
"use strict"和return fn(...)，依然会爆栈
尾位置判断比看起来更苛刻
“写在最后一行”不等于尾调用。真正生效需同时满足：
- 调用必须是函数执行流的最后一步操作，中间不能有隐式计算（如
return 1 + f()中的加法） - 不能出现在
try/catch/finally块内 - 不能在
async函数中使用await后调用（await引入Promise链，破坏纯调用语义） - 函数体内若访问
arguments、caller或外层闭包变量，多数引擎会直接禁用TCO
可用替代方案及其权衡
既然不能依赖引擎，就得主动应对：
立即学习“Java免费学习笔记（深入）”；
-
手写循环：零开销、全环境兼容、性能最优。把尾递归参数转为局部变量，把递归调用转为
while体，例如factorial(n, acc)→while (n > 1) { acc *= n; n--; } - 蹦床函数（trampoline）：保留函数式风格，但每次返回一个函数，由外层循环驱动执行。避免栈溢出，代价是额外函数对象创建和间接调用开销
-
不推荐转译方案：Babel曾提供
proposal-tailcall-optimization插件，但因底层无引擎支持，现代构建链已弃用
为什么还要写尾递归形式？
它不是为了被优化，而是作为迭代逻辑的设计草图。一个合法的尾递归函数（如fib(n, a, b)）已经清晰表达了：状态变量有哪些、怎么更新、何时终止。从它转成while循环，只是语法替换，几乎没有思维转换成本。这种结构化思维本身，比是否真能“优化”更有长期价值。
