我在StackOverflow上找到了一个关于哪些语言支持尾递归优化的问题。这里是链接。为什么C#不会在可能的情况下优化尾递归？
举个具体例子，为什么这个方法不能被优化成循环（在Visual Studio 2008 32位版本中，如果有影响的话）：
private static void Foo(int i)
{
if (i == 1000000)
return;
if (i % 100 == 0)
Console.WriteLine(i);
Foo(i+1);
}
while 循环）。而 C# 的 csc 则不会。
请查看这篇博客文章以了解一些细节（可能已经过时，因为最近的JIT更改）。请注意，CLR 4.0的更改x86、x64和ia64将予以尊重。
这个Microsoft Connect反馈提交应该可以回答你的问题。它包含了来自Microsoft的官方回复，所以建议按照那个做。
感谢您的建议。在C#编译器的开发过程中，我们曾经考虑过在许多时候发出尾调用指令。然而，有一些微妙的问题迫使我们迄今为止避免使用.tail指令：1）在CLR中使用.tail指令实际上会产生非常显著的开销成本（它不仅仅是一个跳转指令，就像在许多较不严格的环境中最终变成的尾调用一样，例如函数式语言运行时环境，在那里尾调用得到了大量优化）。2）实际上很少有真正的C#方法可以合法地发出尾调用（其他语言鼓励具有更多尾递归的编码模式，并且许多依赖于尾调用优化的语言实际上进行全局重写（例如Continuation Passing 转换）来增加尾递归的数量）。3）部分是因为2），由于深度递归导致C#方法堆栈溢出的情况相当罕见。
总之，我们继续研究这个问题，可能会在未来的编译器版本中找到一些模式，在这些模式下发出.tail指令是有意义的。
顺便说一句，正如已经指出的那样，在x64上尾递归被优化了。
C#并没有优化尾递归，因为这正是F#的目的所在！
关于C#编译器无法执行尾调用优化的详细条件，请参阅这篇文章：JIT CLR tail-call conditions。
C#和F#之间的互操作性
C#和F#之间的互操作性非常良好，由于.NET公共语言运行时（CLR）是设计用于此互操作性的，因此每种语言都具有特定于其意图和目的的优化。一个示例显示了从C#代码中调用F#代码有多容易，见Calling F# code from C# code；调用C#函数的F#代码示例，请参阅Calling C# functions from F#。
有关委托互操作性，请参阅此文章：F#、C#和Visual Basic之间的委托互操作性。
C#和F#之间的理论和实际差异
这是一篇涵盖了一些差异并解释了尾递归设计差异的文章，它适用于C#和F#：在C#和F#中生成尾调用操作码。
这是一篇包含C#、F#和C++\CLI示例的文章：在C#、F#和C++\CLI中进行尾递归探险。
主要的理论区别在于，C#是基于循环设计的，而F#则是基于Lambda演算原理设计的。关于Lambda演算原理的一本非常好的书籍，请参见此免费书籍：计算机程序的构造和解释，作者Abelson、Sussman和Sussman。我最近得知C#的64位编译器可以优化尾递归。
C#同样实现了这一点。但它没有被总是应用的原因是，用于应用尾递归的规则非常严格。
long Factorial(int n, long acc = 1)
{
if (n <= 1)
return acc;
return Factorial(n - 1, n * acc);
}
以下是此功能生成的X64汇编代码：
注意，没有call，只有jmp。此函数也经过了激进的优化（没有堆栈帧设置/拆卸）。太好了！
var myFuncExpression = System.Linq.Expressions.Expression.Lambda<Func< … >>(body: … , tailCall: true, parameters: … );
var myFunc = myFuncExpression.Compile();