从这里的任何答案中我都没有看到的一件事是，“去”解决方案通常比经常提到的结构化编程解决方案更有效。

考虑多嵌套循环的情况，其中使用'goto'而不是一堆if(breakVariable)节显然更有效。“将循环放入函数并使用return”的解决方案通常是完全不合理的。在循环可能使用局部变量的情况下，现在必须通过函数参数传递它们，可能会处理由此产生的额外麻烦。

现在考虑一下清理情况，我自己经常使用这种情况，而且这种情况非常常见，可能是try{} catch{}结构在许多语言中都不可用的原因。完成相同任务所需的检查和额外变量的数量远比完成跳转所需的一两个指令要糟糕得多，而且，额外的函数解决方案根本不是解决方案。你不能告诉我这更容易管理或更易于阅读。

现在，代码空间、堆栈使用和执行时间在许多情况下对许多程序员来说可能还不够重要，但当您在一个只有2KB代码空间的嵌入式环境中工作时，为了避免一个明确定义的“goto”而额外执行50字节的指令是可笑的，而且这种情况并不像许多高级程序员所认为的那样罕见。

“goto有害”这句话对迈向结构化编程非常有帮助，即使它总是一种过度概括。在这一点上，我们都听到了足够多的使用它的谨慎(我们应该)。当它显然是工作的正确工具时，我们不需要害怕它。

原论文应该被认为是“无条件GOTO被认为是有害的”。它特别提倡一种基于条件(if)和迭代(while)结构的编程形式，而不是早期代码常见的测试-跳转。Goto在某些语言或环境中仍然有用，因为这些语言或环境不存在适当的控制结构。

实际上，我发现自己不得不使用goto，因为我真的想不出更好(更快)的方法来编写这段代码:

我有一个复杂的对象，我需要对它做一些操作。如果对象处于一种状态，那么我就可以进行快速操作，否则我就必须进行慢速操作。问题是，在某些情况下，在缓慢的手术过程中，可能会意识到这可以用快速手术来完成。

SomeObject someObject;    

if (someObject.IsComplex())    // this test is trivial
{
    // begin slow calculations here
    if (result of calculations)
    {
        // just discovered that I could use the fast calculation !
        goto Fast_Calculations;
    }
    // do the rest of the slow calculations here
    return;
}

if (someObject.IsmediumComplex())    // this test is slightly less trivial
{
    Fast_Calculations:
    // Do fast calculations
    return;
}

// object is simple, no calculations needed.

这是一个实时UI代码的速度关键部分，所以我真的认为GOTO在这里是合理的。

Hugo

几乎所有可以使用goto的情况，都可以使用其他结构实现相同的效果。无论如何，编译器都会使用Goto。

我个人从来没有明确地使用它，也不需要。

Goto很有用，这里有一个用c++写的非常强大的开源象棋引擎stockfish的例子。goto只是跳过了一些条件检查(效率增益)，如果没有goto语句，程序就必须这样做。如果goto语句标签位于goto声明之后，那么它们就非常无害且可读。

如果你用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;
}

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