核心看栈空间占用、执行时间、是否触发栈溢出；普通递归空间复杂度O(n)，尾递归优化后为O(1)；实际效果取决于语言和编译器是否支持尾调用优化（TCO）。

衡量普通递归与尾递归的优化效果，核心看三点：栈空间占用、执行时间、是否触发栈溢出。实际效果取决于语言支持和编译器优化，不能只看代码写法。

栈空间使用量是首要指标

普通递归每层调用都压入新栈帧，空间复杂度为 O(n)；尾递归若被优化，复用同一栈帧，空间复杂度降为 O(1)。可通过调试工具或运行时监控验证：

• 在 C++ 中启用 -fsanitize=stack 或用 Valgrind 观察栈增长趋势
• 在 Python（CPython）中，sys.getrecursionlimit() 和实际崩溃深度可反推栈压力——尾递归版本通常能跑更深而不崩
• JavaScript（V8 严格模式下）可用 console.memory 配合递归深度测试，观察内存驻留变化

执行时间差异需控制变量对比

单纯比耗时容易受编译器内联、缓存等因素干扰，应固定输入规模、关闭无关优化后测量：

• 对同一问题（如计算 10⁴ 级阶乘或求和），分别运行普通递归与尾递归版本各 100 次，取中位数耗时
• C++ 中开启 -O2 后，尾递归常被编译器转为循环，耗时接近迭代；而普通递归仍保留函数调用开销
• 注意：未启用尾调用优化（TCO）的语言（如标准 Python）中，尾递归写法仅逻辑上“尾”，实际栈空间并未节省

栈溢出临界点是最直观的验证方式

这是最贴近工程风险的指标。设定递归深度从 1000 逐步增至 20000，记录首次崩溃的 n 值：

• 普通递归往往在 n ≈ 1000–3000 区间崩溃（取决于系统默认栈大小）
• 尾递归在支持 TCO 的环境（如 Scala、Erlang、Rust -O，或 JavaScript 严格模式+现代 V8）中可稳定运行至 n > 10⁵
• 若尾递归版本同样崩溃，说明当前运行时未启用优化——此时它只是“伪尾递归”，仅结构符合，无实质收益

额外建议：别忽略可读性与维护成本

性能提升不是唯一目标。尾递归常需引入累加参数（如 acc），逻辑更抽象；普通递归更贴近数学定义，易理解。在深度不大（如 n