这里有一个例子，而不是用文字来解释。这是阶乘函数的Scheme版本：

(define (factorial x)
  (if (= x 0) 1
      (* x (factorial (- x 1)))))

下面是一个阶乘的尾部递归版本：

(define factorial
  (letrec ((fact (lambda (x accum)
                   (if (= x 0) accum
                       (fact (- x 1) (* accum x))))))
    (lambda (x)
      (fact x 1))))

在第一个版本中，您会注意到对事实的递归调用被馈送到乘法表达式中，因此在进行递归调用时，状态必须保存在堆栈中。在尾部递归版本中，没有其他S表达式等待递归调用的值，并且由于没有进一步的工作要做，状态不必保存在堆栈上。通常，Scheme尾部递归函数使用常数堆栈空间。

这里是前面提到的tailrecsum函数的Perl 5版本。

sub tail_rec_sum($;$){
  my( $x,$running_total ) = (@_,0);

  return $running_total unless $x;

  @_ = ($x-1,$running_total+$x);
  goto &tail_rec_sum; # throw away current stack frame
}

对我来说，理解尾调用递归的最好方法是递归的一种特殊情况，其中最后一个调用（或尾调用）是函数本身。

比较Python中提供的示例：

def recsum(x):
 if x == 1:
  return x
 else:
  return x + recsum(x - 1)

^递归

def tailrecsum(x, running_total=0):
  if x == 0:
    return running_total
  else:
    return tailrecsum(x - 1, running_total + x)

^尾部递归

正如您在常规递归版本中看到的，代码块中的最后一个调用是x+recsum（x-1）。所以在调用recsum方法之后，还有一个操作是x+。。。

然而，在尾部递归版本中，代码块中的最后一个调用（或尾部调用）是tailrecsum（x-1，running_total+x），这意味着最后一次调用是对方法本身进行的，之后不再进行操作。

这一点很重要，因为这里看到的尾部递归不会使内存增长，因为当底层VM看到一个函数在尾部位置（函数中要计算的最后一个表达式）调用自己时，它会消除当前堆栈帧，这就是所谓的尾部调用优化（TCO）。

EDIT

没有。请记住，上面的示例是用Python编写的，其运行时不支持TCO。这只是一个解释这一点的例子。在Scheme、Haskell等语言中支持TCO

如果每个递归情况仅由对函数本身的调用组成，并且可能具有不同的参数，则函数是尾部递归的。或者，尾部递归是没有待定工作的递归。注意，这是一个与编程语言无关的概念。

考虑定义如下的函数：

g(a, b, n) = a * b^n

一种可能的尾部递归公式是：

g(a, b, n) | n is zero = a
           | n is odd  = g(a*b, b,   n-1)
           | otherwise = g(a,   b*b, n/2)

如果您检查g（…）的每一个涉及递归情况的RHS，您会发现整个RHS都是对g（……）的调用，仅此而已。这个定义是尾部递归的。

作为比较，非尾部递归公式可能是：

g'(a, b, n) = a * f(b, n)
f(b, n) | n is zero = 1
        | n is odd  = f(b, n-1) * b
        | otherwise = f(b, n/2) ^ 2

f（…）中的每个递归情况都有一些需要在递归调用之后进行的未决工作。

注意，当我们从“g”到“g”时，我们充分利用了关联性（和交换性）乘法。这并不是偶然的，在大多数需要将递归转换为尾递归的情况下，都会利用这些财产：如果我们想急切地做一些工作，而不是让它等待，我们必须使用关联性之类的东西来证明答案是一样的。

尾部递归调用可以通过向后跳转来实现，而不是使用堆栈进行常规递归调用。注意，检测尾部呼叫或发出向后跳转通常很简单。然而，通常很难重新排列参数，以便向后跳转。由于此优化不是免费的，语言实现可以选择不实现此优化，或者通过使用“tailcall”指令标记递归调用和/或选择更高的优化设置来要求选择加入。

然而，某些语言（例如Scheme）确实需要所有实现来优化尾部递归函数，甚至可能需要所有尾部位置的调用。

在大多数命令式语言中，向后跳转通常被抽象为（while）循环，而尾部递归在优化为向后跳转时，与循环同构。

许多人已经在这里解释了递归。我想引用Riccardo Terrell的《.NET中的并发性，并发和并行编程的现代模式》一书中关于递归的一些优点的一些想法：

“函数递归是FP中迭代的自然方式，因为它避免状态突变。在每次迭代期间，都会传递一个新值而不是被更新（变异）。在里面此外，可以编写递归函数，使您的程序更加模块化，并引入了开发机会并行化。"

以下是同一本书中关于尾部递归的一些有趣注释：

尾部调用递归是一种转换规则递归的技术函数转换为可处理大型输入的优化版本没有任何风险和副作用。注：尾部调用作为优化的主要原因是提高数据位置、内存使用率和缓存使用率。通过做尾巴调用时，被调用者使用与调用者相同的堆栈空间。这减少了记忆压力。它略微改善了缓存，因为存储器被后续调用方重用，并且可以留在缓存中，而不是驱逐旧的缓存线，为新的缓存腾出空间线

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

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

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

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

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

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

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

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