我遇到过goto是一个很好的解决方案的情况，我在这里或其他地方都没有看到过这个例子。

我有一个开关的情况下，所有的情况都需要调用相同的函数在最后。我有其他的情况，最后都需要调用不同的函数。

这看起来有点像这样:

switch( x ) {
    
    case 1: case1() ; doStuffFor123() ; break ;
    case 2: case2() ; doStuffFor123() ; break ;
    case 3: case3() ; doStuffFor123() ; break ;
    
    case 4: case4() ; doStuffFor456() ; break ;
    case 5: case5() ; doStuffFor456() ; break ;
    case 6: case6() ; doStuffFor456() ; break ;
    
    case 7: case7() ; doStuffFor789() ; break ;
    case 8: case8() ; doStuffFor789() ; break ;
    case 9: case9() ; doStuffFor789() ; break ;
}

我没有给每个case一个函数调用，而是用goto代替了break。goto跳转到一个标签，这也是在开关的情况下。

switch( x ) {
    
    case 1: case1() ; goto stuff123 ;
    case 2: case2() ; goto stuff123 ;
    case 3: case3() ; goto stuff123 ;
    
    case 4: case4() ; goto stuff456 ;
    case 5: case5() ; goto stuff456 ;
    case 6: case6() ; goto stuff456 ;
    
    case 7: case7() ; goto stuff789 ;
    case 8: case8() ; goto stuff789 ;
    case 9: case9() ; goto stuff789 ;
    
    stuff123: doStuffFor123() ; break ;
    stuff456: doStuffFor456() ; break ;
    stuff789: doStuffFor789() ; break ;
}

案例1到3都必须调用doStuffFor123()，类似的案例4到6必须调用doStuffFor456()等。

在我看来，如果你正确使用它们，gotos是非常好的。最后，任何代码都像人们写的那样清晰。有了gotos，你可以写出意大利面代码，但这并不意味着gotos是意大利面代码的原因。这个事业就是我们;程序员。如果我愿意，我也可以用函数创建意大利面条代码。宏也是如此。

因为goto使得程序流的推理变得困难。“意大利面条代码”)，goto通常只用于弥补缺失的功能:使用goto实际上可能是可以接受的，但前提是语言没有提供更结构化的变体来获得相同的目标。以《怀疑》为例:

我们使用的goto规则是，goto可以跳转到函数中的单个退出清理点。

这是对的——但前提是语言不允许使用清理代码进行结构化异常处理(如RAII或finally)，后者可以更好地完成相同的工作(因为它是专门为此而构建的)，或者有很好的理由不使用结构化异常处理(但除非在非常低的级别，否则您永远不会遇到这种情况)。

在大多数其他语言中，goto唯一可接受的用法是退出嵌套循环。即使在这种情况下，将外部循环提升为自己的方法并使用return也总是更好。

除此之外，goto是对特定代码段考虑不够的标志。

支持goto实现一些限制的现代语言(例如，goto可能不会跳转到函数中或跳出函数)，但问题从根本上还是一样的。

顺便说一句，其他语言特性当然也是如此，尤其是例外。而且通常有严格的规则，只在指定的地方使用这些特性，例如不使用异常来控制非异常程序流的规则。

如果有，为什么?

C语言没有多级/标记的中断，并不是所有的控制流都可以用C语言的迭代和决策原语轻松建模。Gotos对纠正这些缺陷大有帮助。

有时使用某种类型的标志变量来实现一种伪多级中断更清晰，但它并不总是优于goto(至少goto可以轻松地确定控制的位置，不像标志变量)，有时您只是不想为了避免goto而付出旗帜/其他扭曲的性能代价。

Libavcodec是一段性能敏感的代码。控制流的直接表达可能是优先考虑的，因为它往往会运行得更好。

我发现do{} while(false)的用法完全令人反感。它可能会让我相信它在某些奇怪的情况下是必要的，但从来没有让我相信它是干净合理的代码。

如果必须执行这样的循环，为什么不显式地依赖标志变量呢?

for (stepfailed=0 ; ! stepfailed ; /*empty*/)

关于goto语句，它们的合法用途，以及可以用来代替“有道德的goto语句”但也可以像goto语句一样容易被滥用的替代结构，最深思熟虑和彻底的讨论是Donald Knuth的文章“使用goto语句的结构化编程”，在1974年12月的Computing Surveys(卷6,no. 1)中。4. 第261 - 301页)。

毫不奇怪，这篇39年前的论文的某些方面已经过时了:处理能力的数量级增长使得Knuth的一些性能改进对于中等规模的问题来说并不明显，从那时起就发明了新的编程语言结构。(例如，try-catch块包含Zahn的Construct，尽管它们很少以这种方式使用。)但Knuth涵盖了争论的方方面面，在任何人再次重复这个问题之前，都应该要求阅读。

盲目地遵循最佳实践并不是最佳实践。避免将goto语句作为流控制的主要形式是为了避免产生难以阅读的意大利面条代码。如果在正确的地方谨慎使用，它们有时可以成为表达想法的最简单、最清晰的方式。Walter Bright, Zortech c++编译器和D编程语言的创造者，经常使用它们，但很明智。即使使用了goto语句，他的代码仍然完全可读。

底线:为了避免去那里而避免去那里是毫无意义的。您真正需要避免的是生成不可读的代码。如果充满goto的代码是可读的，那么它就没有任何问题。