这意味着不需要将指令指针推到堆栈上，只需跳到递归函数的顶部并继续执行即可。这允许函数无限递归而不会溢出堆栈。

我写了一篇关于这个主题的博客文章，里面有堆栈框架的图形示例。

这意味着不需要将指令指针推到堆栈上，只需跳到递归函数的顶部并继续执行即可。这允许函数无限递归而不会溢出堆栈。

我写了一篇关于这个主题的博客文章，里面有堆栈框架的图形示例。

下面是比较两个函数的快速代码片段。第一种是传统的递归，用于求给定数的阶乘。第二种使用尾部递归。

理解起来非常简单直观。

判断递归函数是否为尾部递归函数的一种简单方法是，它是否在基本情况下返回具体值。这意味着它不会返回1或true或类似的值。它很可能会返回某个方法参数的变体。

另一种方法是判断递归调用是否没有任何加法、算术、修改等。这意味着它只是一个纯递归调用。

public static int factorial(int mynumber) {
    if (mynumber == 1) {
        return 1;
    } else {            
        return mynumber * factorial(--mynumber);
    }
}

public static int tail_factorial(int mynumber, int sofar) {
    if (mynumber == 1) {
        return sofar;
    } else {
        return tail_factorial(--mynumber, sofar * mynumber);
    }
}

考虑一个将前N个自然数相加的简单函数。（例如，和（5）＝0+1+2+3+4+5＝15）。

下面是一个使用递归的简单JavaScript实现：

function recsum(x) {
    if (x === 0) {
        return 0;
    } else {
        return x + recsum(x - 1);
    }
}

如果调用recsum（5），JavaScript解释器将评估以下内容：

recsum(5)
5 + recsum(4)
5 + (4 + recsum(3))
5 + (4 + (3 + recsum(2)))
5 + (4 + (3 + (2 + recsum(1))))
5 + (4 + (3 + (2 + (1 + recsum(0)))))
5 + (4 + (3 + (2 + (1 + 0))))
5 + (4 + (3 + (2 + 1)))
5 + (4 + (3 + 3))
5 + (4 + 6)
5 + 10
15

请注意，在JavaScript解释器开始实际计算和之前，每个递归调用都必须完成。

下面是同一函数的尾部递归版本：

function tailrecsum(x, running_total = 0) {
    if (x === 0) {
        return running_total;
    } else {
        return tailrecsum(x - 1, running_total + x);
    }
}

以下是调用tailrecsum（5）时发生的事件序列（由于默认的第二个参数，它实际上是tailrecsum（5，0））。

tailrecsum(5, 0)
tailrecsum(4, 5)
tailrecsum(3, 9)
tailrecsum(2, 12)
tailrecsum(1, 14)
tailrecsum(0, 15)
15

在尾部递归情况下，每次对递归调用求值时，running_total都会更新。

注：原始答案使用了Python中的示例。由于Python解释器不支持尾部调用优化，这些代码已更改为JavaScript。然而，虽然尾部调用优化是ECMAScript 2015规范的一部分，但大多数JavaScript解释器不支持它。

为了理解尾部调用递归和非尾部调用递归之间的一些核心区别，我们可以探索这些技术的.NET实现。

这是一篇包含C#、F#和C++\CLI中的一些示例的文章：C#、F#和C++/CLI中的尾部递归冒险。

C#没有针对尾部调用递归进行优化，而F#进行了优化。

原理的差异涉及循环与Lambda演算。C#的设计考虑到了循环，而F#是基于Lambda演算的原理构建的。有关Lambda微积分原理的一本非常好（免费）的书，请参阅Abelson、Sussman和Sussman的《计算机程序的结构和解释》。

关于F#中的尾部调用，有关非常好的介绍性文章，请参阅F#中尾部调用的详细介绍。最后，这里有一篇文章介绍了非尾部递归和尾部调用递归（在F#中）之间的区别：尾部递归与F sharp中的非尾部递归。

如果您想了解C#和F#之间尾部调用递归的一些设计差异，请参阅在C#和F#中生成尾部调用操作码。

如果您非常想知道哪些条件阻止C#编译器执行尾部调用优化，请参阅本文：JIT CLR尾部调用条件。

这个问题有很多很好的答案。。。但我忍不住提出了另一种看法，即如何定义“尾部递归”，或者至少是“正确的尾部递归”。即：是否应该将其视为程序中特定表达式的属性？还是应该将其视为编程语言实现的属性？

关于后一种观点，Will Clinger的一篇经典论文“正确的尾部递归和空间效率”（PLDI 1998）将“正确的尾递归”定义为编程语言实现的属性。该定义被构造为允许忽略实现细节（例如调用堆栈实际上是通过运行时堆栈还是通过堆分配的帧链接列表表示的）。

为了实现这一点，它使用了渐近分析：不是人们通常看到的程序执行时间，而是程序空间使用情况。这样，堆分配的链接列表与运行时调用堆栈的空间使用最终是渐近等价的；因此，人们会忽略编程语言实现的细节（这一细节在实践中当然非常重要，但当试图确定给定的实现是否满足“属性尾部递归”的要求时，可能会让事情变得一团糟）

该论文值得仔细研究，原因如下：

它给出了程序尾部表达式和尾部调用的归纳定义。（这样的定义，以及为什么这样的电话很重要，似乎是这里给出的大多数其他答案的主题。）以下是这些定义，只是为了提供文本的味道：定义1以核心方案编写的程序的尾部表达式归纳如下。lambda表达式的主体是尾部表达式如果（如果E0 E1 E2）是尾部表达式，则E1和E2都是尾部表达式。其他的都不是尾部表达式。定义2尾部调用是作为过程调用的尾部表达式。

（尾部递归调用，或者正如论文所说，“self-tail调用”是尾部调用的一种特殊情况，其中过程本身被调用。）

它为评估核心方案的六个不同“机器”提供了正式定义，其中每个机器都具有相同的可观察行为，除了每个机器所处的渐近空间复杂性类。例如，在为分别为1。基于堆栈的内存管理，2。垃圾收集，但没有尾部调用。垃圾收集和尾部调用，本文继续介绍更高级的存储管理策略，如4。“evlis尾部递归”，在尾部调用的最后一个子表达式参数求值期间不需要保存环境，5。将闭包的环境减少到该闭包的自由变量，以及6。Appel和Shao定义的所谓“空间安全”语义。为了证明这些机器实际上属于六个不同的空间复杂性类，本文针对每对被比较的机器，提供了程序的具体示例，这些程序将揭示一台机器上的渐近空间爆炸，而不是另一台机器。

（现在仔细阅读我的答案，我不确定我是否真的抓住了克林格论文的关键点。但是，唉，我现在不能花更多的时间来研究这个答案。）