在我看来，人们似乎非常不喜欢这种goto说法，所以我觉得有必要理清这一点。
我相信人们的“情感” goto最终归结为对代码的理解以及对可能的性能影响的（误解）。因此，在回答问题之前，我将首先介绍有关如何编译的一些细节。
众所周知，C＃被编译为IL，然后使用SSA编译器将其编译为汇编器。我将对所有这些工作原理有一些见解，然后尝试回答问题本身。
从C＃到IL
首先，我们需要一段C＃代码。让我们开始简单：
foreach (var item in array)
{
// ...
break;
// ...
}
我将逐步进行此操作，以使您对幕后发生的事情有个很好的了解。
第一个翻译：从foreach到等效for循环（注意：我在这里使用数组，因为我不想深入了解IDisposable的详细信息-在这种情况下，我还必须使用IEnumerable）：
for (int i=0; i<array.Length; ++i)
{
var item = array[i];
// ...
break;
// ...
}
第二种翻译：for和break被翻译成更容易的等价形式：
int i=0;
while (i < array.Length)
{
var item = array[i];
// ...
break;
// ...
++i;
}
和第三翻译（这是等效的IL代码）：我们改变break并while进入了一个分支：
int i=0; // for initialization
startLoop:
if (i >= array.Length) // for condition
{
goto exitLoop;
}
var item = array[i];
// ...
goto exitLoop; // break
// ...
++i; // for post-expression
goto startLoop;
尽管编译器只需一步即可完成这些操作，但它可以让您深入了解该过程。从C＃程序演变而来的IL代码是最后C＃代码的字面翻译。您可以在这里自己看到：https : //dotnetfiddle.net/QaiLRz（单击“查看IL”）
现在，您在这里观察到的一件事是，在此过程中，代码变得更加复杂。观察这一点的最简单方法是，我们需要越来越多的代码来说明同一件事。您可能还认为foreach，for，while和break实际上短期手中goto，这部分是真实的。
从IL到汇编器
.NET JIT编译器是SSA编译器。我不会在这里讨论SSA表单的所有详细信息以及如何创建优化的编译器，这虽然太多了，但可以对将会发生的事情提供基本的了解。为了获得更深入的了解，最好开始阅读优化编译器（我确实喜欢这本书作为简短介绍：http : //ssabook.gforge.inria.fr/latest/book.pdf //ssabook.gforge.inria.fr/latest/book.pdf）和LLVM（llvm.org） 。
每个优化的编译器都依赖于这样的事实，即代码很容易并且遵循可预测的模式。对于FOR循环，我们使用图论来分析分支，然后在分支中优化诸如Cycli之类的东西（例如，向后分支）。
但是，我们现在有了前向分支来实现我们的循环。您可能已经猜到了，这实际上是JIT要修复的第一步，如下所示：
int i=0; // for initialization
if (i >= array.Length) // for condition
{
goto endOfLoop;
}
startLoop:
var item = array[i];
// ...
goto endOfLoop; // break
// ...
++i; // for post-expression
if (i >= array.Length) // for condition
{
goto startLoop;
}
endOfLoop:
// ...
如您所见，我们现在有一个向后分支，这是我们的小循环。这里唯一仍然令人讨厌的是由于我们的break声明而最终导致的分支。在某些情况下，我们可以以相同的方式移动它，但在其他情况下，它仍然存在。
那么，为什么编译器会这样做呢？好吧，如果我们可以展开循环，则可以对它进行矢量化处理。我们甚至可以证明只添加了常量，这意味着我们的整个循环可能消失了。总结：通过使模式可预测（使分支可预测），我们可以证明某些条件存在于我们的循环中，这意味着我们可以在JIT优化过程中做魔术。
但是，分支趋向于破坏那些很好的可预测模式，这是优化程序所不喜欢的。打破，继续，前进-他们都打算打破这些可预测的模式-因此并不是真正的“好”。
在这一点上，您还应该认识到，比起遍布各处foreach的一堆goto语句，更容易预测。从（1）可读性和（2）从优化器的角度来看，这都是更好的解决方案。
值得一提的另一件事是，优化编译器将寄存器分配给变量（称为寄存器分配的过程）非常重要。您可能知道，CPU中只有有限数量的寄存器，它们是迄今为止硬件中最快的内存。最内层循环中的代码中使用的变量更有可能分配一个寄存器，而循环外的变量则不太重要（因为此代码的命中率可能会降低）。
帮助，太复杂了...我该怎么办？
最重要的是，您应该始终使用您可以使用的语言构造，这通常（隐式）将为编译器构建可预测的模式。尽量避免陌生的分支（如果可能具体是：break，continue，goto或return在没有任何中间）。
好消息是这些可预测的模式既易于阅读（对于人类）又易于发现（对于编译器）。
这些模式之一称为SESE，它表示单入口单出口。
现在我们解决了真正的问题。
假设您有这样的事情：
// a is a variable.
for (int i=0; i<100; ++i)
{
for (int j=0; j<100; ++j)
{
// ...
if (i*j > a)
{
// break everything
}
}
}
使这种模式可预测的最简单方法是完全消除以下内容if：
int i, j;
for (i=0; i<100 && i*j <= a; ++i)
{
for (j=0; j<100 && i*j <= a; ++j)
{
// ...
}
}
在其他情况下，您也可以将方法分为2种方法：
// Outer loop in method 1:
for (i=0; i<100 && processInner(i); ++i)
{
}
private bool processInner(int i)
{
int j;
for (j=0; j<100 && i*j <= a; ++j)
{
// ...
}
return i*j<=a;
}
临时变量？好不好还是丑陋？
您甚至可能决定从循环内返回一个布尔值（但我个人更喜欢SESE形式，因为这是编译器将其看到的方式，并且我认为它更易于阅读）。
有人认为使用临时变量比较干净，并提出如下解决方案：
bool more = true;
for (int i=0; i<100; ++i)
{
for (int j=0; j<100; ++j)
{
// ...
if (i*j > a) { more = false; break; } // yuck.
// ...
}
if (!more) { break; } // yuck.
// ...
}
// ...
我个人反对这种方法。再看一下代码是如何编译的。现在考虑一下如何使用这些好的可预测模式。拿图片吗
是的，让我说清楚。将会发生的是：
- 编译器会将所有内容写为分支。
- 作为优化步骤，编译器将进行数据流分析，以尝试删除
more仅在控制流中使用的奇怪变量。
- 如果成功，该变量
more将从程序中删除，仅保留分支。这些分支将得到优化，因此您只能从内部循环中获得一个分支。
- 如果不成功，则该变量
more肯定会在最内层循环中使用，因此，如果编译器无法对其进行优化，则很有可能将其分配给寄存器（这会耗尽宝贵的寄存器内存）。
因此，总而言之：编译器中的优化器将陷入困境，以至于找出more仅用于控制流的情况，并且在最佳情况下，会将其转换为外部的单个分支，以便循环。
换句话说，最好的情况是最终将达到以下效果：
for (int i=0; i<100; ++i)
{
for (int j=0; j<100; ++j)
{
// ...
if (i*j > a) { goto exitLoop; } // perhaps add a comment
// ...
}
// ...
}
exitLoop:
// ...
我对此的个人意见很简单：如果这一直是我们一直想要的目标，那么让我们简化编译器和可读性的工作，并立即编写它。
tl; dr：
底线：
- 如果可能，在for循环中使用简单的条件。尽可能使用您可以使用的高级语言构造。
- 如果一切都失败了，或者您选择了
goto或bool more，则最好选择前者。