由于所有内容都有限制，所以我想知道嵌套for循环的数量是否有限制，或者只要我有内存，就可以添加它们，Visual Studio编译器可以创建这样的程序吗？

当然，64个或更多的嵌套for循环不便于调试，但是可行吗？

private void TestForLoop()
{
  for (int a = 0; a < 4; a++)
  {
    for (int b = 0; b < 56; b++)
    {
      for (int c = 0; c < 196; c++)
      {
        //etc....
      }
    }
  }
}

我要发布此内容，但我认为答案是：

550至575之间

^{在Visual Studio 2015中使用默认设置}

我创建了一个生成嵌套for循环的小程序...

for (int i0=0; i0<10; i0++)
{
    for (int i1=0; i1<10; i1++)
    {
        ...
        ...
        for (int i573=0; i573<10; i573++)
        {
            for (int i574=0; i574<10; i574++)
            {
                Console.WriteLine(i574);
            }
        }
        ...
        ...
    }
}

对于500个嵌套循环，仍可以编译该程序。有了575个循环，编译器可以解决以下问题：

警告AD0001分析器'Microsoft.CodeAnalysis.CSharp.Diagnostics.SimplifyTypeNames.CSharpSimplifyTypeNamesDiagnosticAnalyzer'引发了类型'System.InsufficientExecutionStackException'的异常，消息为'堆栈不足，无法继续安全地执行程序。这可能是由于调用堆栈上的函数过多或使用过多堆栈空间的堆栈上的函数造成的。

与底层的编译器消息

错误CS8078：表达式太长或太复杂而无法编译

当然，这纯粹是假设的结果。如果最里面的循环的作用大于a Console.WriteLine，则在超出堆栈大小之前，可能会出现较少的嵌套循环。同样，在可能存在隐藏设置的情况下，这可能不是严格的技术限制，以增加错误消息中提及的“分析器”或（如果需要）生成的可执行文件的最大堆栈大小。但是，答案的这一部分留给了深入了解C＃的人。

更新资料

针对评论中的问题：

我很想看到这个答案可以扩展为通过实验“证明”是否可以将575个局部变量（如果未在for循环中使用）放在堆栈上，和/或是否可以在其中放入575个非嵌套的for循环。单一功能

对于这两种情况，答案都是：是的，有可能。用575个自动生成的语句填充方法时

int i0=0;
Console.WriteLine(i0);
int i1=0;
Console.WriteLine(i1);
...
int i574=0;
Console.WriteLine(i574);

它仍然可以编译。其他一切都会令我惊讶。int变量所需的堆栈大小仅为2.3 KB。但是我很好奇，为了测试更多的限制，我增加了这个数字。最终，它并不能编译，导致错误

错误CS0204：仅允许65534个本地人，包括由编译器生成的本地人

这是一个有趣的观点，但是已经在其他地方观察到：方法中的最大变量数

同样，有575个非嵌套 for循环，例如

for (int i0=0; i0<10; i0++)
{
    Console.WriteLine(i0);
}
for (int i1=0; i1<10; i1++)
{
    Console.WriteLine(i1);
}
...
for (int i574=0; i574<10; i574++)
{
    Console.WriteLine(i574);
}

也可以编译。在这里，我还试图找到极限，并创建了更多的循环。特别是，我不确定这种情况下的循环变量是否也计入als“ locals”，因为它们是独立存在的{ block }。但是仍然不能超过65534。最后，我添加了一个由40000个循环的模式组成的测试

for (int i39999 = 0; i39999 < 10; i39999++)
{
    int j = 0;
    Console.WriteLine(j + i39999);
}

在循环中包含一个额外的变量，但这些变量似乎也算作“局部变量”，因此无法对其进行编译。

总结一下：〜550的限制确实是由循环的嵌套深度引起的。错误消息也表明了这一点

错误CS8078：表达式太长或太复杂而无法编译

很遗憾（但可以理解）错误CS1647的文档未指定复杂性的“度量”，而仅给出了实用的建议。

编译器在处理您的代码时发生堆栈溢出。要解决此错误，请简化您的代码。

再次强调这一点：对于深度嵌套for循环的特殊情况，所有这些都是相当学术性和假设性的。但是，通过网络搜索CS1647的错误消息，发现了几种情况，其中该错误针对的代码似乎不是故意有意创建的，而是在现实情况下产生的。

C＃语言规范或CLR中没有硬性限制。您的代码将是迭代的，而不是递归的，这可能会很快导致堆栈溢出。

有一些事情可以算作一个阈值，例如int您将使用的（通常）计数器，它将int为每个循环分配一个内存（在为您的整个堆栈分配ints之前）。请注意，必须使用，int并且您可以重复使用相同的变量。

正如Marco所指出的，当前的阈值在编译器中要比实际语言规范或运行时中的阈值更多。重新编码后，您可能需要进行更多迭代。例如，如果使用Ideone（默认情况下使用旧的编译器），则可以for轻松获得1200个以上的循环。

这么多的for循环是不良设计的指标。我希望这个问题纯粹是假设的。

所有编译为MSIL的C＃都有一个限制。MSIL仅支持65535个局部变量。如果for循环类似于示例中所示，则每个循环都需要一个变量。

您的编译器可能会在堆上分配对象以充当局部变量的存储，从而规避了此限制。但是，我不确定会从中得出什么样的结果。反射可能会导致使这种方法非法的问题。

空for(;;)循环在800和900之间。

反映了Marco13的方法，但尝试过的for(;;)循环除外：

for (;;)  // 0
for (;;)  // 1
for (;;)  // 2
// ...
for (;;)  // n_max
{
  // empty body
}

它适用于800个嵌套for(;;)，但给出的错误与Marco13尝试900个循环时遇到的错误相同。

当它确实编译时，for(;;)似乎在不使CPU耗尽的情况下阻塞了线程。从表面上看，它看起来像一个Thread.Sleep()。