凡事無絕對，任何技術都有適合它的場景。技術用好了就是寶刀，用爛了就是炸彈。

技術沒有好與壞，主要在於用它的人，也就是程式設計師的水平。

並不能把goto當成絕對不能用的東西，比如c語言中用goto實現類似高階語言中的try finally 資源回收就非常常見。

再比如，c#中非常優秀（被nodejs等很多直接抄襲）的async、await就是在底層被編譯器生成了使用goto實現的狀態機，程式碼見圖。

其他的邏輯跳轉都是goto的包裝，它們都可以簡化程式碼邏輯，但是不可完全替代goto，畢竟goto是可以無條件跳轉到任何地方的。

比如一個深層迴圈，想要一下跳出來，不用goto得用無數個break。

所以不能因噎廢食。

當然你自己可以約束自己，為了可讀性，儘量不用稀奇古怪的goto。

這問題真沒意義。只想隨口說一句，goto是最接近彙編/機器碼的語句。高階語言為了保護傻瓜程式設計師，反而擯棄了很多彙編裡的高效跳轉。

現在高階語言程式設計師都不關注計算機最底層的東西了，以前的程式設計師對計算機和作業系統的基礎功底要求還是蠻高的，使用goto還有指標特別方便，但是需要程式設計師控制它的收放，現在高階語言把這塊要不給禁了，要不垃圾回收給你做了。

goto語句在結構化程式設計的今天，的確不再推廣，因為大量使用goto語句，使得程式可讀性非常差，邏輯上也容易出錯。

微軟在vc推出時，提出了結構化程式的概念。即，儘可能使用子程式。每一個子程式完成一個小的功能，按順序，就象寫文章一樣，條理清楚，可讀性強，便於維護。

但是，任何事情都有例外。

1，與老的軟體相容。我們做的軟體，有很多是從上世紀繼承而來。如底層的差分，積分，語法語義的解析，已經是成熟的模組了。現在要再用到系統中，如果編繹器不支援goto，必須重新編輯，出bug的可能性又增加了。

2，程式設計還有一個規則，即每個子程式，只在結尾返回，儘可能少在中間位量用return。這樣容易漏掉象free記憶體，或者Release老的mPen這樣的錯誤，導致系統崩潰。所以，在中間return，又要處理一個公共程式塊，用goto就比較完美。如：

void calculateafun（）

{

int a，b，c，d；

char *p=new char[10000];

if（a==b）

{

.....大於1000行程式,有幾十個return

//有很多分枝要return,但須先free（p）

//加goto CommonProcess;

else

{

.......大於1000行,有幾十個return,

//同樣很多return,也要先釋放p.

//加goto CommonProcess;

}

CommonProcess:

free（p）

return;

}

當然，有點牽強，只是為了後期維護時，好替換。

短程式goto確實還挺好用，但是一旦程式碼一長，問題一複雜，goto就不好用了，會使程式碼查錯還是可讀性都下降

顯然是“我可以不用，但是你不能沒有”系列。

假想你有三個for迴圈巢狀，大多數高階語言你可以用return徹底退出所有迴圈，用break退出當前迴圈。但是如果想一下子跳出兩個迴圈怎麼辦？ 這個時候就有用了。

許多時候開發者根本不想寫出複雜的巢狀。但是深入行業就知道，許多行業業務複雜度是難以想象的。陳舊積累下來的程式碼n個巢狀很多了。

多分支錯誤歸一處理不用goto，不但程式碼更難懂，你還可以去試試程式碼多了多少？

類似的例子多了去了。