在我的程序列表中，Goto只是为了它而包含的东西非常低。这并不意味着这是不可接受的。

Goto可以很好地用于状态机。循环中的switch语句(按典型重要性排序):(A)不能实际代表控制流，(b)丑陋，(c)可能效率低下，这取决于语言和编译器。因此，您最终为每个状态编写一个函数，并执行类似“return NEXT_STATE;”的操作，这甚至看起来像goto。

当然，以易于理解的方式对状态机进行编码是很困难的。然而，这些困难都与使用goto无关，也不能通过使用替代控制结构来减少。除非你的语言有一个“状态机”结构。我不喜欢。

在极少数情况下，当您的算法通过通过有限的允许转换集(goto)连接的节点(状态)序列的路径而不是通过任何更具体的控制流(循环、条件等等)来理解时，那么应该在代码中显式地说明这一点。你应该画一个漂亮的图。

Setjmp /longjmp可以很好地实现异常或类似异常的行为。虽然没有得到普遍的赞扬，但异常通常被认为是一种“有效的”控制结构。

Setjmp /longjmp比goto“更危险”，因为它们更难正确使用，更不用说理解了。

从来没有，将来也不会有 永远是，任何语言都是 写不好一点也难 代码。——唐纳德·克努特

从C中去掉goto并不会使用C编写好的代码变得更容易。事实上，这样做反而会忽略一点，即C应该能够作为一种被美化的汇编语言。

接下来是“有害的指针”，然后是“有害的鸭子类型”。那么，当他们来拿走你不安全的编程结构时，谁来保护你呢?是吗?

如果你用C写一个VM，使用(gcc的)计算gotos是这样的:

char run(char *pc) {
    void *opcodes[3] = {&&op_inc, &&op_lda_direct, &&op_hlt};
    #define NEXT_INSTR(stride) goto *(opcodes[*(pc += stride)])
    NEXT_INSTR(0);
    op_inc:
    ++acc;
    NEXT_INSTR(1);
    op_lda_direct:
    acc = ram[++pc];
    NEXT_INSTR(1);
    op_hlt:
    return acc;
}

工作速度比循环内的传统开关快得多。

c++包含构造函数和析构函数。这允许一种称为RAII(资源分配是初始化)的模式。基本上，您创建一个本地堆栈变量，创建堆栈变量的行为打开一个文件，分配内存，锁定一个互斥锁，或以其他方式获取一个稍后必须释放的资源。

当变量超出作用域时，析构函数将运行并释放资源。

C语言没有这个特性。但您仍然经常需要在函数开始时获取资源，并在结束时释放它们。

你的函数可能有一个或多个错误条件导致它提前返回。您不希望重复资源释放代码。解决方案是使用goto。

例子:

int
foo(const char *arg)
{
    char *argcopy = strdup(arg);

    if (!isvalid(argcopy))
        goto out1;

    FILE *myfile = fopen(argcopy, "r");
    if (myfile == NULL)
      goto out1;

    char bytes[10];
    if (fread(bytes, sizeof(bytes), 1, myfile) != sizeof(mybytes))
        goto out2;

    /* do some actual work */
    /* .... */
    /* end of actual work */

    out2:
    fclose(myfile);

    out1:
    free(argcopy);

    return 0;
 }

后藤认为他很有帮助。

我从1975年开始编程。对于20世纪70年代的程序员来说，“goto被认为是有害的”这个词或多或少地表明，具有现代控制结构的新编程语言值得一试。我们确实尝试了新的语言。我们很快就皈依了。我们再也没有回去过。

我们再也没有回去过，但是，如果你更年轻，那么你就从来没有去过那里。

现在，拥有古老编程语言的背景可能并没有太大用处，除非它能显示程序员的年龄。尽管如此，年轻的程序员缺乏这方面的背景，所以他们不再理解口号“goto被认为是有害的”在引入时向目标受众传达的信息。

一个人不理解的口号是不太有启发性的。也许最好忘记这些口号。这样的口号无济于事。

然而，这个特别的口号，“后藤有害”，已经有了它自己的不死生命。

能去不被虐待吗?回答:当然，但那又怎样?实际上，每一个编程元素都可能被滥用。例如，普通bool被滥用的次数比我们中的一些人愿意相信的要多。

相比之下，自1990年以来，我不记得遇到过一次真正的goto滥用案例。

goto最大的问题可能不是技术问题，而是社交问题。不太懂的程序员有时似乎觉得不赞成goto会让他们听起来很聪明。您可能需要不时地满足这样的程序员。生活就是这样。

今天goto最糟糕的事情是它没有被充分使用。

没有所谓的GOTO被认为是有害的。

GOTO是一种工具，和所有工具一样，它可以被使用和滥用。

然而，在编程世界中有许多工具倾向于被滥用而不是被使用，GOTO就是其中之一。Delphi的WITH语句是另一个。

就我个人而言，我在典型的代码中不使用这两种方法，但我有过GOTO和WITH的奇怪用法，这是有保证的，另一种解决方案将包含更多的代码。

最好的解决方案是编译器只警告你关键字被污染了，你必须在语句周围塞几个pragma指令来消除警告。

这就像告诉你的孩子不要拿着剪刀跑。剪刀并不坏，但使用它们可能不是保持健康的最佳方式。

因为goto可以用于令人困惑的元编程

Goto既是高级控件表达式，也是低级控件表达式，因此它没有适合大多数问题的合适设计模式。

它是低级的，因为goto是一个基本操作，它实现了一些高级操作，比如while或foreach之类的。

从某种意义上说，它是高级的，当以某种方式使用时，它将以一种清晰的顺序执行的代码，以一种不间断的方式(除了结构化循环)，并将其转换为逻辑片段，这些逻辑片段有足够的gotos，可以动态地重新组装逻辑。

所以，有平淡的一面，也有邪恶的一面。

平淡的一面是，一个向上指向的goto可以实现一个完全合理的循环，而一个向下指向的goto可以执行一个完全合理的中断或返回。当然，实际的while、break或return语句可读性更强，因为可怜的人不需要为了了解全局而模拟goto语句的效果。总的来说，这是个坏主意。

The evil side involves a routine not using goto for while, break, or return, but using it for what's called spaghetti logic. In this case the goto-happy developer is constructing pieces of code out of a maze of goto's, and the only way to understand it is to simulate it mentally as a whole, a terribly tiring task when there are many goto's. I mean, imagine the trouble of evaluating code where the else is not precisely an inverse of the if, where nested ifs might allow in some things that were rejected by the outer if, etc, etc.

Finally, to really cover the subject, we should note that essentially all early languages except Algol initially made only single statements subject to their versions of if-then-else. So, the only way to do a conditional block was to goto around it using an inverse conditional. Insane, I know, but I've read some old specs. Remember that the first computers were programmed in binary machine code so I suppose any kind of an HLL was a lifesaver; I guess they weren't too picky about exactly what HLL features they got.

说了这么多，我曾经在我写的每个程序中都加了一个go，“只是为了惹恼那些纯粹主义者”。