尾调用优化（TCO）是运行时环境在严格模式下、满足尾位置调用等条件时自动复用栈帧的机制，核心是用jmp跳转替代call调用，将空间复杂度从O(n)降至O(1)，但目前仅Safari稳定支持，Chrome与Firefox因调试和兼容性问题未启用。
尾调用优化（Tail Call Optimization，TCO）不是靠程序员手动“写出来”的技巧，而是运行时环境在满足特定条件时，对函数执行上下文进行的自动栈帧复用机制。它的核心目标很明确：避免递归或链式调用导致调用栈无限增长。
什么是尾位置？决定能否优化的关键
尾位置（tail position）指函数体中**最后一个被执行且直接返回结果的表达式所在的位置**。它不看语法缩进或行号，而看控制流——函数执行到这一步后，再无任何后续操作，立即把结果交出去。
- ✅ 合法尾调用：
return helper(x)、return g(a, b)、return fn(...args) - ❌ 非尾调用：
return x + helper(y)（加法需等待 helper 返回）、console.log('done'); return f(z)（有副作用语句）、const r = f(); return r * 2（需二次计算）
执行上下文如何被复用？栈帧替换过程
普通函数调用会为每次调用新建一个执行上下文（含变量环境、词法环境、this、arguments、返回地址等），压入调用栈。而尾调用优化发生时，引擎会：
- 检查当前函数是否处于严格模式（ES6 要求 TCO 仅在严格模式下生效）
- 确认调用位于尾位置，且被调函数不是间接调用（如
(f)()或eval('f()')） - 用新参数覆盖当前栈帧的参数和局部变量区域
- 复用当前帧的返回地址，改用跳转（
jmp）而非调用（call）指令进入目标函数 - 原函数的执行上下文不再保留，不会等待返回——它已“交出控制权”
为什么多数 JavaScript 引擎没真正启用 TCO？
ES6 标准确实规定：在严格模式下，符合尾调用条件的场景必须做优化。但现实是：
- Safari 是目前唯一稳定支持完整 TCO 的主流引擎（从 WebKit 76 开始）
- V8（Chrome/Node.js）曾短暂实现又移除，主因是调试体验受损（丢失调用栈信息）、与 async/await 和 try-catch 的交互复杂、性能收益在多数 Web 场景中不明显
- Firefox 的 SpiderMonkey 也未启用，优先保障开发者工具可用性
这意味着：你写了合法的尾递归，代码语法没错，但绝大多数环境下仍会创建新栈帧——它只是“可优化”，并非“已优化”。
实践中怎么应对？不依赖引擎，自己掌控栈
既然运行时支持不可靠，就该用确定性策略替代：
- 手动将尾递归转为 while 循环（累加器变量外提）
- 使用蹦床函数（trampoline）：返回函数而非直接调用，由外层循环驱动执行
- 对深度不确定的递归任务（如 AST 遍历、状态机流转），优先采用显式栈（数组 push/pop）模拟递归
- 保持尾调用写法本身仍有价值——逻辑清晰、便于静态分析、未来引擎支持后可零成本受益
