———文章來源 YamiOdymel/PHP-to-Golang
專注于為中小企業(yè)提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)蒲城免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
PHP和模塊之間的關(guān)系令人感到煩躁，假設(shè)你要讀取 yaml 檔案，你需要有一個 yaml 的模塊，為此，你還需要將其編譯然后將編譯后的模塊擺放至指定位置，之后換了一臺伺服器你還要重新編譯，這點(diǎn)到現(xiàn)在還是沒有改善；順帶一提之后出了PHP 7效能確實(shí)提升了許多（比Python 3快了些），但PHP仍令我感到臃腫，我覺得是時候
（轉(zhuǎn)行）了。
PHP 和Golang 的效能我想毋庸置疑是后者比較快（而且是以倍數(shù)來算），也許有的人會認(rèn)為兩種不應(yīng)該被放在一起比較，但Golang 本身就是偏向Web 開發(fā)的，所以這也是為什么我考慮轉(zhuǎn)用Golang 的原因，起初我的考慮有幾個：Node.js 和Rust 還有最終被選定的Golang；先談?wù)凬ode.js 吧。
Node.js的效能可以說是快上PHP 3.5倍至6倍左右 ，而且撰寫的語言還是JavaScript，蒸蚌，如此一來就不需要學(xué)習(xí)新語言了！搭配Babel更可以說是萬能，不過那跟「跳跳虎」一樣的Async邏輯還有那恐怖的Callback Hell，有人認(rèn)為前者是種優(yōu)點(diǎn)，這點(diǎn)我不否認(rèn)，但是對學(xué)習(xí)PHP的我來說太過于"Mind Fuck"，至于后者的Callback Hell雖然有Promise，但是那又是另一個「Then Hell」的故事了。相較于Golang之下，Node.js似乎就沒有那么吸引我了。你確實(shí)可以用Node.js寫出很多東西，不過那V8引擎的效能仍然有限，而且要學(xué)習(xí)新的事物，不就應(yīng)該是「全新」的嗎;)？
題外話： 為什么Node.js不適合大型和商業(yè)專案？
在拋棄改用Node.js 之后我曾經(jīng)花了一天的時間嘗試Rust 和Iron 框架，嗯??Rust 太強(qiáng)大了，強(qiáng)大到讓我覺得Rust 不應(yīng)該用在這里，這想法也許很蠢，但Rust 讓我覺得適合更應(yīng)該拿來用在系統(tǒng)或者是部分底層的地方，而不應(yīng)該是網(wǎng)路服務(wù)。
Golang是我最終的選擇，主要在于我花了一天的時間來研究的時候意外地發(fā)現(xiàn)Golang夭壽簡潔（ 關(guān)鍵字只有25個 ），相較之下Rust太過于「強(qiáng)大」令我怯步；而且Golang帶有許多工具，例如 go fmt 會自動幫你整理程式碼、 go doc 會自動幫你生產(chǎn)文件、 go test 可以自動單元測試并生產(chǎn)覆蓋率報表、也有 go get 套件管理工具（雖然沒有版本功能），不過都很實(shí)用，而且也不需要加上分號（ ; ），真要說不好的地方??大概就是強(qiáng)迫你花括號不能換行放吧（沒錯，我就是花括號會換行放的人）。
當(dāng)我在撰寫這份文件的時候 我會先假設(shè)你有一定的基礎(chǔ) ，你可以先閱讀下列的手冊，他們都很不錯。
你能夠在PHP 里面想建立一個變數(shù)的時候就直接建立，夭壽贊，是嗎？
蒸蚌！那么Golang 呢？在Golang 中變數(shù)分為幾類：「新定義」、「預(yù)先定義」、「自動新定義」、「覆蓋」。讓我們來看看范例：
在PHP中你會很常用到 echo 來顯示文字，像這樣。
然而在Golang中你會需要 fmt 套件，關(guān)于「什么是套件」的說明你可以在文章下述了解。
這很簡單，而且兩個語言的用法相差甚少，下面這是PHP：
只是Golang 稍微聒噪了一點(diǎn)，你必須在函式后面宣告他最后會回傳什么資料型別。
在PHP 中你要回傳多個資料你就會用上陣列，然后將資料放入陣列里面，像這樣。
然而在Golang 中你可以不必用到一個陣列，函式可以一次回傳多個值：
兩個語言的撰寫方式不盡相同。
主要是PHP 的陣列能做太多事情了，所以在PHP 里面要儲存什么用陣列就好了。
在Golang里??沒有這么萬能的東西，首先要先了解Golang中有這些型態(tài)： array , slice , map , interface ，
你他媽的我到底看了三洨，首先你要知道Golang是個強(qiáng)型別語言，意思是你的陣列中 只能有一種型態(tài) ，什么意思？當(dāng)你決定這個陣列是用來擺放字串資料的時候，你就只能在里面放字串。沒有數(shù)值、沒有布林值，就像你沒有女朋友一樣。
先撇開PHP 的「萬能陣列」不管，Golang 中的陣列既單純卻又十分腦殘，在定義一個陣列的時候，你必須給他一個長度還有其內(nèi)容存放的資料型態(tài)，你的陣列內(nèi)容不一定要填滿其長度，但是你的陣列內(nèi)容不能超過你當(dāng)初定義的長度。
切片??這聽起來也許很奇怪，但是你確實(shí)可以「切」他，讓我們先談?wù)劇盖衅贡绕稹戈嚵小挂迷谀睦铮骸改悴挥枚x其最大長度，而且你可以直接賦予值」，沒了。
我們剛才有提到你可以「切」他，記得嗎？這有點(diǎn)像是PHP中的 array_slice() ，但是Golang直接讓Slice「內(nèi)建」了這個用法，其用法是： slice[開始:結(jié)束] 。
在PHP中倒是沒有那么方便，在下列PHP范例中你需要不斷地使用 array_slice() 。
你可以把「映照」看成是一個有鍵名和鍵值的陣列，但是記?。骸改阈枰孪榷x其鍵名、鍵值的資料型態(tài)」，這仍限制你沒辦法在映照中存放多種不同型態(tài)的資料。
在Golang里可就沒這么簡單了，你需要先用 make() 宣告 map 。
也許你不喜歡「接口」這個詞，但用「介面」我怕會誤導(dǎo)大眾，所以，是的，接下來我會繼續(xù)稱其為「接口」。還記得你可以在PHP 的關(guān)聯(lián)陣列里面存放任何型態(tài)的資料嗎，像下面這樣？
現(xiàn)在你有福了！正因為Golang中的 interface{} 可以接受任何內(nèi)容，所以你可以把它拿來存放任何型態(tài)的資料。
有時候你也許會有個不定值的變數(shù)，在PHP 里你可以直接將一個變數(shù)定義成字串、數(shù)值、空值、就像你那變心的女友一樣隨時都在變。
在Golang中你必須給予變數(shù)一個指定的資料型別，不過還記得剛才提到的：「Golang中有個 interface{} 能夠 存放任何事物 」嗎（ 雖然也不是真的任何事物啦?? ）？
當(dāng)我們程式中不需要繼續(xù)使用到某個資源或是發(fā)生錯誤的時候，我們索性會將其關(guān)閉或是拋棄來節(jié)省資源開銷，例如PHP 里的讀取檔案：
在Golang中，你可以使用 defer 來在函式結(jié)束的時候自動執(zhí)行某些程式(其執(zhí)行方向為反向)。所以你就不需要在函式最后面結(jié)束最前面的資源。
defer 可以被稱為「推遲執(zhí)行」，實(shí)際上就是在函式結(jié)束后會「反序」執(zhí)行的東西，例如你按照了這樣的順序定義 defer ： A-B-C-D ，那么執(zhí)行的順序其實(shí)會是 D-C-B-A ，這用在程式結(jié)束時還蠻有用的，讓我們看看Golang如何改善上述范例。
這東西很邪惡，不是嗎？又不是在寫B(tài)ASIC，不過也許有時候你會在PHP 用上呢。但是拜托，不要。
Golang中僅有 for 一種回圈但卻能夠達(dá)成 foreach 、 while 、 for 多種用法。普通 for 回圈寫法在兩個語言中都十分相近。
在Golang請記得：如果你的 i 先前并不存在，那么你就需要定義它，所以下面這個范例你會看見 i := 0 。
在PHP里， foreach() 能夠直接給你值和鍵名，用起來十分簡單。
Golang里面雖然僅有 for() 但卻可以使用 range 達(dá)成和PHP一樣的 foreach 方式。
一個 while(條件) 回圈在PHP里面可以不斷地執(zhí)行區(qū)塊中的程式，直到 條件 為 false 為止。
在Golang里也有相同的做法，但仍是透過 for 回圈，請注意這個 for 回圈并沒有任何的分號（ ; ），而且一個沒有條件的 for 回圈會一直被執(zhí)行。
PHP中有 do .. while() 回圈可以先做區(qū)塊中的動作。
在Golang中則沒有相關(guān)函式，但是你可以透過一個無止盡的 for 回圈加上條件式來讓他結(jié)束回圈。
要是你真的希望完全符合像是PHP那樣的設(shè)計方式，或者你可以在Golang中使用很邪惡的 goto 。
在PHP中我們可以透過 date() 像這樣取得目前的日期。
在Golang就稍微有趣點(diǎn)了，因為Golang中并不是以 Y-m-d 這種格式做為定義，而是 1 、 2 、 3 ，這令你需要去翻閱文件，才能夠知道 1 的定義是代表什么。
俗話說：「爆炸就是藝術(shù)」，可愛的PHP用詞真的很大膽，像是： explode() （爆炸）、 die() （死掉），回歸正傳，如果你想在PHP里面將字串切割成陣列，你可以這么做。
簡單的就讓一個字串給「爆炸」了，那么Golang 呢？
對了，記得引用 strings 套件。
這真的是很常用到的功能，就像物件一樣有著鍵名和鍵值，在PHP 里面你很簡單的就能靠陣列（Array）辦到。
真是太棒了，那么Golang呢？用 map 是差不多啦。如果有必要的話，你可以稍微復(fù)習(xí)一下先前提到的「多資料儲存型態(tài)－Stores」。
你很常會在PHP里面用 isset() 檢查一個索引是否存在，不是嗎？
在Golang里面很簡單的能夠這樣辦到（僅適用于 map ）。
指針（有時也做參照）是一個像是「變數(shù)別名」的方法，這種方法讓你不用整天覆蓋舊的變數(shù)，讓我們假設(shè) A = 1; B = A; 這個時候 B 會復(fù)制一份 A 且兩者不相干，倘若你希望修改 B 的時候?qū)嶋H上也會修改到 A 的值，就會需要指針。
指針比起復(fù)制一個變數(shù)，他會建立一個指向到某個變數(shù)的記憶體位置，這也就是為什么你改變指針，實(shí)際上是在改變某個變數(shù)。
在Golang你需要用上 * 還有 符號。
有些時候你會回傳一個陣列，這個陣列里面可能有資料還有錯誤代號，而你會用條件式判斷錯誤代號是否非空值。
在Golang中函式可以一次回傳多個值。為此，你不需要真的回傳一個陣列，不過要注意的是你將會回傳一個屬于 error 資料型態(tài)的錯誤，所以你需要引用 errors 套件來幫助你做這件事。
該注意的是Golang沒有 try .. catch ，因為 Golang推薦這種錯誤處理方式 ，你應(yīng)該在每一次執(zhí)行可能會發(fā)生錯誤的程式時就處理錯誤，而非后來用 try 到處包覆你的程式。
在 if 條件式里宣告變數(shù)會讓你只能在 if 內(nèi)部使用這個變數(shù)，而不會污染到全域范圍。
也許你在PHP中更常用的會是 try .. catch ，在大型商業(yè)邏輯時經(jīng)?？匆娙绱说赜梅?，實(shí)際上這種用法令人感到聒噪（因為你會需要一堆 try 區(qū)塊）：
Golang中并沒有 try .. catch ，實(shí)際上Golang也 不鼓勵這種行為 （Golang推薦逐一處理錯誤的方式），倘若你真想辦倒像是捕捉異常這樣的方式，你確實(shí)可以使用Golang中另類處理錯誤的方式（可以的話盡量避免使用這種方式）： panic() , recover() , defer 。
你可以把 panic() 當(dāng)作是 throw （丟出錯誤），而這跟PHP的 exit() 有87%像，一但你執(zhí)行了 panic() 你的程式就會宣告而終，但是別擔(dān)心，因為程式結(jié)束的時候會呼叫 defer ，所以我們接下來要在 defer 停止 panic() 。
關(guān)于 defer 上述已經(jīng)有提到了，他是一個反向執(zhí)行的宣告，會在函式結(jié)束后被執(zhí)行，當(dāng)你呼叫了 panic() 結(jié)束程式的時候，也就會開始執(zhí)行 defer ，所以我們要在 defer 內(nèi)使用 recover() 讓程式不再繼續(xù)進(jìn)行結(jié)束動作，這就像是捕捉異常。
recover() 可以看作 catch （捕捉），我們要在 defer 里面用 recover() 解決 panic() ，如此一來程式就會回歸正常而不會被結(jié)束。
還記得在PHP里要引用一堆檔案的日子嗎？到處可見的 require() 或是 include() ？到了Golang這些都不見了，取而代之的是「套件（Package）」?，F(xiàn)在讓我們來用PHP解釋一下。
這看起來很正常對吧？但假設(shè)你有一堆檔案，這馬上就成了 Include Hell ，讓我們看看Golang怎么透過「套件」解決這個問題。
「 蛤？？？殺?。?？？ 」你可能如此地說道。是的， main.go 中除了引用 fmt 套件（ 為了要輸出結(jié)果用的套件 ）之外完全沒有引用到 a.go 。
「 蛤？？？殺??？？？？？？ 」你仿佛回到了幾秒鐘前的自己。
既然沒有引用其他檔案，為什么 main.go 可以輸出 foo 呢？注意到了嗎， 兩者都是屬于 main 套件 ，因此 他們共享同一個區(qū)域 ，所以接下來要介紹的是什么叫做「套件」。
套件是每一個 .go 檔案都必須聲明在Golang原始碼中最開端的東西，像下面這樣：
這意味著目前的檔案是屬于 main 套件（ 你也可以依照你的喜好命名 ），那么要如何讓同個套件之間的函式溝通呢？
接著是Golang；注意！你不需要引用任何檔案，因為下列兩個檔案同屬一個套件。
一個由「套件」所掌握的世界，比起PHP的 include() 和 require() 還要好太多了，對嗎？
在Golang 中沒有引用單獨(dú)檔案的方式，你必須匯入一整個套件，而且你要記住：「一定你匯入了，你就一定要使用它」，像下面這樣。
假如你不希望使用你匯入的套件，你只是為了要觸發(fā)那個套件的 main() 函式而引用的話??，那么你可以在前面加上一個底線（ _ ）。
如果你的套件出現(xiàn)了名稱沖突，你可以在套件來源前面給他一個新的名稱。
現(xiàn)在你知道可以匯入套件了，那么什么是「匯出」？同個套件內(nèi)的函式還有共享變數(shù)確實(shí)可以直接用，但那 并不表示可以給其他套件使用 ，其方法取決于 函式／變數(shù)的「開頭大小寫」 。
是的。 Golang依照一個函式／變數(shù)的開頭大小寫決定這個東西是否可供「匯出」 。
這用在區(qū)別函式的時候格外有用，因為小寫開頭的任何事物都是不供匯出的，反之，大寫開頭的任何事物都是用來匯出供其他套件使用的。
一開始可能會覺得這是什么奇異的規(guī)定，但寫久之后，你就能發(fā)現(xiàn)比起JavaScript和Python以「底線為開頭的命名方式」還要來得更好；比起成天宣告 public 、 private 、 protected 還要來得更快。
在Golang 中沒有類別，但有所謂的「建構(gòu)體（Struct）」和「接口（Interface）」，這就能夠滿足幾乎所有的需求了，這也是為什么我認(rèn)為Golang 很簡潔卻又很強(qiáng)大的原因。
讓我們先用PHP 建立一個類別，然后看看Golang 怎么解決這個問題。
雖然Golang沒有類別，但是「建構(gòu)體（Struct）」就十分地堪用了，首先你要知道在Golang中「類別」的成員還有方法都是在「類別」外面所定義的，這跟PHP在類別內(nèi)定義的方式有所不同，在Golang中還有一點(diǎn)，那就是他們沒有 public 、 private 、 protected 的種類。
在PHP中，當(dāng)有一個類別被 new 的時候會自動執(zhí)行該類別內(nèi)的建構(gòu)子（ __construct() ），通常你會用這個來初始化一些類別內(nèi)部的值。
但是在Golang 里因為沒有類別，也就沒有建構(gòu)子，不巧的是建構(gòu)體本身也不帶有建構(gòu)子的特性，這個時候你只能自己在外部建立一個建構(gòu)用函式。
讓我們假設(shè)你有兩個類別，你會把其中一個類別傳入到另一個類別里面使用，廢話不多說！先上個PHP 范例（為了簡短篇幅我省去了換行）。
在Golang中你也有相同的用法，但是請記得：「 任何東西都是在「類別」外完成建構(gòu)的 」。
在PHP 中沒有相關(guān)的范例，這部分會以剛才「嵌入」章節(jié)中的Golang 范例作為解說對象。
你可以看見Golang在進(jìn)行 Foo 嵌入 Bar 的時候，會自動將 Foo 的成員暴露在 Bar 底下，那么假設(shè)「雙方之間有相同的成員名稱」呢？
這個時候被嵌入的成員就會被「遮蔽」，下面是個實(shí)際范例，還有你如何解決遮蔽問題：
雖然都是呼叫同一個函式，但是這個函式可以針對不同的資料來源做出不同的舉動，這就是多形。你也能夠把這看作是：「訊息的意義由接收者定義，而不是傳送者」。
目前PHP 中沒有真正的「多形」，不過你仍可以做出同樣的東西。
嗯??那么Golang呢？實(shí)際上更簡單而且更有條理了，在Golang中有 interface 可以幫忙完成這個工作。
如果你對Interface還不熟悉，可以試著查看「 解釋Golang中的Interface到底是什么 」文章。
謝謝你看到這里，可惜這篇文章卻沒有說出Golang 最重要的賣點(diǎn)：「Goroutine」和「Channel」
try to do sth.是個固定搭配 努力 盡量做某事 這個go 就是do
句子：我盡量回去.
云和安全管理服務(wù)專家新鈦云服 張春翻譯
這種方法有幾個缺點(diǎn)。首先，它可以對程序員隱藏錯誤處理路徑，特別是在捕獲異常不是強(qiáng)制性的情況下，例如在 Python 中。即使在具有必須處理的 Java 風(fēng)格的檢查異常的語言中，如果在與原始調(diào)用不同的級別上處理錯誤，也并不總是很明顯錯誤是從哪里引發(fā)的。
我們都見過長長的代碼塊包裝在一個 try-catch 塊中。在這種情況下，catch 塊實(shí)際上充當(dāng) goto 語句，這通常被認(rèn)為是有害的（奇怪的是，C 中的關(guān)鍵字被認(rèn)為可以接受的少數(shù)用例之一是錯誤后清理，因為該語言沒有 Golang- 樣式延遲語句）。
如果你確實(shí)從源頭捕獲異常，你會得到一個不太優(yōu)雅的 Go 錯誤模式版本。這可能會解決混淆代碼的問題，但會遇到另一個問題：性能。在諸如 Java 之類的語言中，拋出異?？赡鼙群瘮?shù)的常規(guī)返回慢數(shù)百倍。
Java 中最大的性能成本是由打印異常的堆棧跟蹤造成的，這是昂貴的，因為運(yùn)行的程序必須檢查編譯它的源代碼 。僅僅進(jìn)入一個 try 塊也不是空閑的，因為需要保存 CPU 內(nèi)存寄存器的先前狀態(tài)，因為它們可能需要在拋出異常的情況下恢復(fù)。
如果您將異常視為通常不會發(fā)生的異常情況，那么異常的缺點(diǎn)并不重要。這可能是傳統(tǒng)的單體應(yīng)用程序的情況，其中大部分代碼庫不必進(jìn)行網(wǎng)絡(luò)調(diào)用——一個操作格式良好的數(shù)據(jù)的函數(shù)不太可能遇到錯誤（除了錯誤的情況）。一旦您在代碼中添加 I/O，無錯誤代碼的夢想就會破滅：您可以忽略錯誤，但不能假裝它們不存在！
try {
doSometing()
} catch (IOException e) {
// ignore it
}
與大多數(shù)其他編程語言不同，Golang 接受錯誤是不可避免的。 如果在單體架構(gòu)時代還不是這樣，那么在今天的模塊化后端服務(wù)中，服務(wù)通常和外部 API 調(diào)用、數(shù)據(jù)庫讀取和寫入以及與其他服務(wù)通信 。
以上所有方法都可能失敗，解析或驗證從它們接收到的數(shù)據(jù)（通常在無模式 JSON 中）也可能失敗。Golang 使可以從這些調(diào)用返回的錯誤顯式化，與普通返回值的等級相同。從函數(shù)調(diào)用返回多個值的能力支持這一點(diǎn)，這在大多數(shù)語言中通常是不可能的。Golang 的錯誤處理系統(tǒng)不僅僅是一種語言怪癖，它是一種將錯誤視為替代返回值的完全不同的方式！
重復(fù) if err != nil
對 Go 錯誤處理的一個常見批評是被迫重復(fù)以下代碼塊：
res, err := doSomething()
if err != nil {
// Handle error
}
對于新用戶來說，這可能會覺得沒用而且浪費(fèi)行數(shù)：在其他語言中需要 3 行的函數(shù)很可能會增長到 12 行 ：
這么多行代碼！這么低效！如果您認(rèn)為上述內(nèi)容不優(yōu)雅或浪費(fèi)代碼，您可能忽略了我們檢查代碼中的錯誤的全部原因：我們需要能夠以不同的方式處理它們！對 API 或數(shù)據(jù)庫的調(diào)用可能會被重試。
有時事件的順序很重要：調(diào)用外部 API 之前發(fā)生的錯誤可能不是什么大問題（因為數(shù)據(jù)從未通過發(fā)送），而 API 調(diào)用和寫入本地數(shù)據(jù)庫之間的錯誤可能需要立即注意，因為 這可能意味著系統(tǒng)最終處于不一致的狀態(tài)。即使我們只想將錯誤傳播給調(diào)用者，我們也可能希望用失敗的解釋來包裝它們，或者為每個錯誤返回一個自定義錯誤類型。
并非所有錯誤都是相同的，并且向調(diào)用者返回適當(dāng)?shù)腻e誤是 API 設(shè)計的重要部分，無論是對于內(nèi)部包還是 REST API 。
不必?fù)?dān)心在你的代碼中重復(fù) if err != nil ——這就是 Go 中的代碼應(yīng)該看起來的樣子。
自定義錯誤類型和錯誤包裝
從導(dǎo)出的方法返回錯誤時，請考慮指定自定義錯誤類型，而不是單獨(dú)使用錯誤字符串。字符串在意外代碼中是可以的，但在導(dǎo)出的函數(shù)中，它們成為函數(shù)公共 API 的一部分。更改錯誤字符串將是一項重大更改——如果沒有明確的錯誤類型，需要檢查返回錯誤類型的單元測試將不得不依賴原始字符串值！事實(shí)上，基于字符串的錯誤也使得在私有方法中測試不同的錯誤案例變得困難，因此您也應(yīng)該考慮在包中使用它們?；氐藉e誤與異常的爭論，返回錯誤也使代碼比拋出異常更容易測試，因為錯誤只是要檢查的返回值。不需要測試框架或在測試中捕獲異常 。
可以在 database/sql 包中找到簡單自定義錯誤類型的一個很好的示例。它定義了一個導(dǎo)出常量列表，表示包可以返回的錯誤類型，最著名的是 sql.ErrNoRows。雖然從 API 設(shè)計的角度來看，這種特定的錯誤類型有點(diǎn)問題（您可能會爭辯說 API 應(yīng)該返回一個空結(jié)構(gòu)而不是錯誤），但任何需要檢查空行的應(yīng)用程序都可以導(dǎo)入該常量并在代碼中使用它不必?fù)?dān)心錯誤消息本身會改變和破壞代碼。
對于更復(fù)雜的錯誤處理，您可以通過實(shí)現(xiàn)返回錯誤字符串的 Error() 方法來定義自定義錯誤類型。自定義錯誤可以包括元數(shù)據(jù)，例如錯誤代碼或原始請求參數(shù)。如果您想表示錯誤類別，它們很有用。DigitalOcean 的本教程展示了如何使用自定義錯誤類型來表示可以重試的一類臨時錯誤。
通常，錯誤會通過將低級錯誤與更高級別的解釋包裝起來，從而在程序的調(diào)用堆棧中傳播。例如，數(shù)據(jù)庫錯誤可能會以下列格式記錄在 API 調(diào)用處理程序中：調(diào)用 CreateUser 端點(diǎn)時出錯：查詢數(shù)據(jù)庫時出錯：pq：檢測到死鎖。這很有用，因為它可以幫助我們跟蹤錯誤在系統(tǒng)中傳播的過程，向我們展示根本原因（數(shù)據(jù)庫事務(wù)引擎中的死鎖）以及它對更廣泛系統(tǒng)的影響（調(diào)用者無法創(chuàng)建新用戶）。
自 Go 1.13 以來，此模式具有特殊的語言支持，并帶有錯誤包裝。通過在創(chuàng)建字符串錯誤時使用 %w 動詞，可以使用 Unwrap() 方法訪問底層錯誤。除了比較錯誤相等性的函數(shù) errors.Is() 和 errors.As() 外，程序還可以獲取包裝錯誤的原始類型或標(biāo)識。這在某些情況下可能很有用，盡管我認(rèn)為在確定如何處理所述錯誤時最好使用頂級錯誤的類型。
Panics
不要 panic()！長時間運(yùn)行的應(yīng)用程序應(yīng)該優(yōu)雅地處理錯誤而不是panic。即使在無法恢復(fù)的情況下（例如在啟動時驗證配置），最好記錄一個錯誤并優(yōu)雅地退出。panic比錯誤消息更難診斷，并且可能會跳過被推遲的重要關(guān)閉代碼。
Logging
我還想簡要介紹一下日志記錄，因為它是處理錯誤的關(guān)鍵部分。通常你能做的最好的事情就是記錄收到的錯誤并繼續(xù)下一個請求。
除非您正在構(gòu)建簡單的命令行工具或個人項目，否則您的應(yīng)用程序應(yīng)該使用結(jié)構(gòu)化的日志庫，該庫可以為日志添加時間戳，并提供對日志級別的控制。最后一部分特別重要，因為它將允許您突出顯示應(yīng)用程序記錄的所有錯誤和警告。通過幫助將它們與信息級日志分開，這將為您節(jié)省無數(shù)時間。
微服務(wù)架構(gòu)還應(yīng)該在日志行中包含服務(wù)的名稱以及機(jī)器實(shí)例的名稱。默認(rèn)情況下記錄這些時，程序代碼不必?fù)?dān)心包含它們。您也可以在日志的結(jié)構(gòu)化部分中記錄其他字段，例如收到的錯誤（如果您不想將其嵌入日志消息本身）或有問題的請求或響應(yīng)。只需確保您的日志沒有泄露任何敏感數(shù)據(jù)，例如密碼、API 密鑰或用戶的個人數(shù)據(jù)！
對于日志庫，我過去使用過 logrus 和 zerolog，但您也可以選擇其他結(jié)構(gòu)化日志庫。如果您想了解更多信息，互聯(lián)網(wǎng)上有許多關(guān)于如何使用這些的指南。如果您將應(yīng)用程序部署到云中，您可能需要日志庫上的適配器來根據(jù)您的云平臺的日志 API 格式化日志 - 沒有它，云平臺可能無法檢測到日志級別等某些功能。
如果您在應(yīng)用程序中使用調(diào)試級別日志（默認(rèn)情況下通常不記錄），請確保您的應(yīng)用程序可以輕松更改日志級別，而無需更改代碼。更改日志級別還可以暫時使信息級別甚至警告級別的日志靜音，以防它們突然變得過于嘈雜并開始淹沒錯誤。您可以使用在啟動時檢查以設(shè)置日志級別的環(huán)境變量來實(shí)現(xiàn)這一點(diǎn)。
原文：
此篇文章流傳甚廣, 其實(shí)里面沒啥干貨， 而且里面很多觀點(diǎn)是有問題的. 這個文章在 golang-china 很早就討論過了.
最近因為 Rust 1.0 和 1.1 的發(fā)布, 導(dǎo)致這個文章又出來毒害讀者.
所以寫了這篇反駁文章, 指出其中的問題.
有好幾次，當(dāng)我想起來的時候，總是會問自己：我為什么要放棄Go語言？這個決定是正確的嗎？是明智和理性的嗎？其實(shí)我一直在認(rèn)真思考這個問題。
開門見山地說，我當(dāng)初放棄Go語言（golang），就是因為兩個“不爽”：第一，對Go語言本身不爽；第二，對Go語言社區(qū)里的某些人不爽。毫無疑問，這是非常主觀的結(jié)論。但是我有足夠詳實(shí)的客觀的論據(jù)，用以支撐這個看似主觀的結(jié)論。
文末附有本文更新日志。
確實(shí)是非常主觀的結(jié)論, 因為里面有不少有問題的觀點(diǎn)(用來忽悠Go小白還行).
第0節(jié)：我的Go語言經(jīng)歷
先說說我的經(jīng)歷吧，以避免被無緣無故地當(dāng)作Go語言的低級黑。
2009年底，Go語言（golang）第一個公開版本發(fā)布，籠罩著“Google公司制造”的光環(huán)，吸引了許多慕名而來的嘗鮮者，我（Liigo）也身居其中，籠統(tǒng)的看了一些Go語言的資料，學(xué)習(xí)了基礎(chǔ)的教程，因?qū)ζ湔Z法中的分號和花括號不滿，很快就遺忘掉了，沒拿它當(dāng)一回事。
在2009年Go剛發(fā)布時, 確實(shí)是因為“Google公司制造”的光環(huán)而吸引了(包括文章作者和諸多IT記者)很多低級的嘗鮮者.
還好, 經(jīng)過5年的發(fā)展, 這些純粹因為光環(huán)來的投機(jī)者所剩已經(jīng)不多了(Google趨勢).
目前, 真正的Go用戶早就將Go用于實(shí)際的生產(chǎn)了.
說到 其語法中的分號和花括號不滿, 我想說這只是你的 個人主觀感受, 還有很多人對Go的分號和花括號很滿意,
包括水果公司的的 Swift 的語言設(shè)計者也很滿意這種風(fēng)格(Swift中的分號和花括號和Go基本相同).
如果只談 個人主觀感受, 我也可以說 Rust 的 fn 縮寫也很蛋疼!
兩年之后，2011年底，Go語言發(fā)布1.0的計劃被提上日程，相關(guān)的報道又多起來，我再次關(guān)注它，重新評估之后決定深入?yún)⑴cGo語言。我訂閱了其users、nuts、dev、commits等官方郵件組，堅持每天閱讀其中的電子郵件，以及開發(fā)者提交的每一次源代碼更新，給Go提交了許多改進(jìn)意見，甚至包括修改Go語言編譯器源代碼直接參與開發(fā)任務(wù)。如此持續(xù)了數(shù)月時間。
這個到是事實(shí), 在 golang-china 有不少吵架的帖子, 感興趣的可以去挖下, 我就不展開說了.
到2012年初，Go 1.0發(fā)布，語言和標(biāo)準(zhǔn)庫都已經(jīng)基本定型，不可能再有大幅改進(jìn)，我對Go語言未能在1.0定型之前更上一個臺階、實(shí)現(xiàn)自我突破，甚至帶著諸多明顯缺陷走向1.0，感到非常失望，因而逐漸疏遠(yuǎn)了它（所以Go 1.0之后的事情我很少關(guān)心）。后來看到即將發(fā)布的Go 1.1的Release Note，發(fā)現(xiàn)語言層面沒有太大改變，只是在庫和工具層面有所修補(bǔ)和改進(jìn)，感到它尚在幼年就失去成長的動力，越發(fā)失望。外加Go語言社區(qū)里的某些人，其中也包括Google公司負(fù)責(zé)開發(fā)Go語言的某些人，其態(tài)度、言行，讓我極度厭惡，促使我決絕地離棄Go語言。
真的不清楚樓主說的可以在 Go1.0 之前短時間內(nèi)能實(shí)現(xiàn)的 重大改進(jìn)和諸多明顯缺陷 是什么.
如果是樓主說前面的 其語法中的分號和花括號不滿 之類的重大改進(jìn), 我只能說這只是你的 個人主觀感受 而已,
你的很多想法只能說服你自己, 沒辦法說服其他絕大部分人(不要以為像C++或Rust那樣什么特性都有就NB了, 各種NB特性加到一起只能是 要你命3000, 而絕對不會是什么 銀彈).
Go 1.1的Release Note，發(fā)現(xiàn)語言層面沒有太大改變. 語言層沒有改變是是因為 Go1 作出的向后兼容的承諾. 對于工業(yè)級的語言來說, Go1 這個只能是優(yōu)點(diǎn). 如果連語言層在每個版本都會出現(xiàn)諸多大幅改進(jìn), 那誰還敢用Go語言來做生產(chǎn)開發(fā)呢(我承認(rèn)Rust的改動很大膽, 但也說明了Rust還處于比較幼稚和任性的階段)?
說 Go語言社區(qū)里的某些人固執(zhí) 的觀點(diǎn)我是同意的. 但是這些 固執(zhí) 的人是可以講道理的, 但是他們對很多東西的要求很高(特別是關(guān)于Go的設(shè)計哲學(xué)部分).
只要你給的建議有依據(jù)(語言的設(shè)計哲學(xué)是另外一回事情), 他們絕對不會盲目的拒絕(只是討論的周期會比較長).
關(guān)于樓主提交的給Go文件添加BOM的文章, 需要補(bǔ)充說明下.
在Go1.0發(fā)布的時候, Go語言的源文件(.go)明確要求必須是UTF8編碼的, 而且是無BOM的UTF8編碼的.
注意: 這個 無BOM的UTF8編碼 的限制僅僅是 針對 Go語言的源文件(.go).
這個限制并不是說不允許用戶處理帶BOM的UTF8的txt文件!
我覺得對于寫Go程序來說, 這個限制是沒有任何問題的, 到目前為止, 我還從來沒有使用過帶BOM的.go文件.
不僅是因為帶BOM的.go文件沒有太多的意義, 而且有很多的缺陷.
BOM的原意是用來表示編碼是大端還是小端的, 主要用于UTF16和UTF32. 對于 UTF8 來說, BOM 沒有任何存在的意義(正是Go的2個作者發(fā)明了UTF8, 徹底解決了全球的編碼問題).
但是, 在現(xiàn)實(shí)中, 因為MS的txt記事本, 對于中文環(huán)境會將txt(甚至是C/C++源文件)當(dāng)作GBK編碼(GBK是個爛編碼),
為了區(qū)別到底是GBK還是UTF8, MS的記事本在前面加了BOM這個垃圾(被GBK占了茅坑), 這里的bom已經(jīng)不是表示字節(jié)序本意了. 不知道有沒有人用ms的記事本寫網(wǎng)頁, 然后生成一個帶bom的utf8網(wǎng)頁肯定很有意思.
這是MS的記事本的BUG: 它不支持生成無BOM的UTF8編碼的文本文件!
這些是現(xiàn)實(shí)存在的帶BOM的UTF8編碼的文本文件, 但是它們肯定都不是Go語言源文件!
所以說, Go語言的源文件即使強(qiáng)制限制了無BOM的UTF8編碼要求, 也是沒有任何問題的(而且我還希望有這個限制).
雖然后來Go源文件接受帶BOM的UTF8了, 但是運(yùn)行 go fmt 之后, 還是會刪除掉BOM的(因為BOM就是然并卵). 也就是說 帶 BOM 的 Go 源文件是不符合 Go語言的編碼風(fēng)格的, go fmt 會強(qiáng)制刪除 BOM 頭.
前面說了BOM是MS帶來的垃圾, 但是BOM的UTF8除了然并卵之外還有很多問題, 因為BOM在string的開頭嵌入了垃圾,
導(dǎo)致正則表達(dá)式, string的鏈接運(yùn)算等操作都被會被BOM這個垃圾所污染. 對于.go語言, 即使代碼完全一樣, 有BOM和無BOM會導(dǎo)致文件的MD5之類的校驗碼不同.
所以, 我覺得Go用戶不用糾結(jié)BOM這個無關(guān)緊要的東西.
在上一個10年，我（Liigo）在我所屬的公司里，深度參與了兩個編程語言項目的開發(fā)。我想，對于如何判斷某個編程語言的優(yōu)劣，或者說至少對于如何判斷某個編程語言是否適合于我自己，我應(yīng)該還是有一點(diǎn)發(fā)言權(quán)的。
第1節(jié)：我為什么對Go語言不爽？
Go語言有很多讓我不爽之處，這里列出我現(xiàn)在還能記起的其中一部分，排名基本上不分先后。讀者們耐心地看完之后，還能淡定地說一句“我不在乎”嗎？
1.1 不允許左花括號另起一行
關(guān)于對花括號的擺放，在C語言、C++、Java、C#等社區(qū)中，十余年來存在持續(xù)爭議，從未形成一致意見。在我看來，這本來就是主觀傾向很重的抉擇，不違反原則不涉及是非的情況下，不應(yīng)該搞一刀切，讓程序員或團(tuán)隊自己選擇就足夠了。編程語言本身強(qiáng)行限制，把自己的喜好強(qiáng)加給別人，得不償失。無論傾向于其中任意一種，必然得罪與其對立的一群人。雖然我現(xiàn)在已經(jīng)習(xí)慣了把左花括號放在行尾，但一想到被禁止其他選擇，就感到十分不爽。Go語言這這個問題上，沒有做到“團(tuán)結(jié)一切可以團(tuán)結(jié)的力量”不說，還有意給自己樹敵，太失敗了。
我覺得Go最偉大的發(fā)明是 go fmt, 從此Go用戶不會再有花括弧的位置這種無聊爭論了(當(dāng)然也少了不少灌水和上tiobe排名的機(jī)會).
是這優(yōu)點(diǎn), Swift 語言也使用和 Go 類似的風(fēng)格(當(dāng)然樓主也可能鄙視swift的作者).
1.2 編譯器莫名其妙地給行尾加上分號
對Go語言本身而言，行尾的分號是可以省略的。但是在其編譯器（gc）的實(shí)現(xiàn)中，為了方便編譯器開發(fā)者，卻在詞法分析階段強(qiáng)行添加了行尾的分號，反過來又影響到語言規(guī)范，對“怎樣添加分號”做出特殊規(guī)定。這種變態(tài)做法前無古人。在左花括號被意外放到下一行行首的情況下，它自動在上一行行尾添加的分號，會導(dǎo)致莫名其妙的編譯錯誤（Go 1.0之前），連它自己都解釋不明白。如果實(shí)在處理不好分號，干脆不要省略分號得了；或者，Scala和JavaScript的編譯器是開源的，跟它們學(xué)學(xué)怎么處理省略行尾分號可以嗎？
又是樓主的 個人主觀感受, 不過我很喜歡這個特性. Swift 語言也是類似.
1.3 極度強(qiáng)調(diào)編譯速度，不惜放棄本應(yīng)提供的功能
程序員是人不是神，編碼過程中免不了因為大意或疏忽犯一些錯。其中有一些，是大家集體性的很容易就中招的錯誤（Go語言里的例子我暫時想不起來，C++里的例子有“基類析構(gòu)函數(shù)不是虛函數(shù)”）。這時候編譯器應(yīng)該站出來，多做一些檢查、約束、核對性工作，盡量阻止常規(guī)錯誤的發(fā)生，盡量不讓有潛在錯誤的代碼編譯通過，必要時給出一些警告或提示，讓程序員留意。編譯器不就是機(jī)器么，不就是應(yīng)該多做臟活累活雜活、減少人的心智負(fù)擔(dān)么？編譯器多做一項檢查，可能會避免數(shù)十萬程序員今后多年內(nèi)無數(shù)次犯同樣的錯誤，節(jié)省的時間不計其數(shù)，這是功德無量的好事。但是Go編譯器的作者們可不這么想，他們不愿意自己多花幾個小時給編譯器增加新功能，覺得那是虧本，反而減慢了編譯速度。他們以影響編譯速度為由，拒絕了很多對編譯器改進(jìn)的要求。典型的因噎廢食。強(qiáng)調(diào)編譯速度固然值得贊賞，但如果因此放棄應(yīng)有的功能，我不贊成。
編譯速度是很重要的, 如果編譯速度夠慢, 語言再好也不會有人使用的.
比如C/C++的增量編譯/預(yù)編譯頭文件/并發(fā)編譯都是為了提高編譯速度.
Rust1.1 也號稱 比 1.0 的編譯時間減少了32% (注意: 不是運(yùn)行速度).
當(dāng)然, Go剛面世的時候, 編譯速度是其中的一個設(shè)計目標(biāo).
不過我想樓主, 可能想說的是因為編譯器自己添加分號而導(dǎo)致的編譯錯誤的問題.
我覺得Go中 { 不能另起一行是語言特性, 如果修復(fù)這個就是引入了新的錯誤.
其他的我真想不起來還有哪些 調(diào)編譯速度，不惜放棄本應(yīng)提供的功能 (不要提泛型, 那是因為還沒有好的設(shè)計).
1.4 錯誤處理機(jī)制太原始
在Go語言中處理錯誤的基本模式是：函數(shù)通常返回多個值，其中最后一個值是error類型，用于表示錯誤類型極其描述；調(diào)用者每次調(diào)用完一個函數(shù)，都需要檢查這個error并進(jìn)行相應(yīng)的錯誤處理：if err != nil { /*這種代碼寫多了不想吐么*/ }。此模式跟C語言那種很原始的錯誤處理相比如出一轍，并無實(shí)質(zhì)性改進(jìn)。實(shí)際應(yīng)用中很容易形成多層嵌套的if else語句，可以想一想這個編碼場景：先判斷文件是否存在，如果存在則打開文件，如果打開成功則讀取文件，如果讀取成功再寫入一段數(shù)據(jù)，最后關(guān)閉文件，別忘了還要處理每一步驟中出現(xiàn)錯誤的情況，這代碼寫出來得有多變態(tài)、多丑陋？實(shí)踐中普遍的做法是，判斷操作出錯后提前return，以避免多層花括號嵌套，但這么做的后果是，許多錯誤處理代碼被放在前面突出的位置，常規(guī)的處理邏輯反而被掩埋到后面去了，代碼可讀性極差。而且，error對象的標(biāo)準(zhǔn)接口只能返回一個錯誤文本，有時候調(diào)用者為了區(qū)分不同的錯誤類型，甚至需要解析該文本。除此之外，你只能手工強(qiáng)制轉(zhuǎn)換error類型到特定子類型（靜態(tài)類型的優(yōu)勢沒了）。至于panic - recover機(jī)制，致命的缺陷是不能跨越庫的邊界使用，注定是一個半成品，最多只能在自己的pkg里面玩一玩。Java的異常處理雖然也有自身的問題（比如Checked Exceptions），但總體上還是比Go的錯誤處理高明很多。
話說, 軟件開發(fā)都發(fā)展了半個世紀(jì), 還是無實(shí)質(zhì)性改進(jìn). 不要以為弄一個異常的語法糖就是革命了.
我只能說錯誤和異常是2個不同的東西, 將所有錯誤當(dāng)作異常那是SB行為.
正因為有異常這個所謂的銀彈, 導(dǎo)致很多等著別人幫忙擦屁股的行為(注意 shit 函數(shù)拋出的絕對不會是一種類型的 shit, 而被其間接調(diào)用的各種 xxx_shit 也可能拋出各種類型的異常, 這就導(dǎo)致 catch 失控了):
int main() {
try {
shit();
} catch( /* 到底有幾千種 shit ? */) {
...
}
}
Go的建議是 panic - recover 不跨越邊界, 也就是要求正常的錯誤要由pkg的處理掉.
這是負(fù)責(zé)任的行為.
再說Go是面向并發(fā)的編程語言, 在海量的 goroutine 中使用 try/catch 是不是有一種不倫不類的感覺呢?
1.5 垃圾回收器（GC）不完善、有重大缺陷
在Go 1.0前夕，其垃圾回收器在32位環(huán)境下有內(nèi)存泄漏，一直拖著不肯改進(jìn)，這且不說。Go語言垃圾回收器真正致命的缺陷是，會導(dǎo)致整個進(jìn)程不可預(yù)知的間歇性停頓。像某些大型后臺服務(wù)程序，如游戲服務(wù)器、APP容器等，由于占用內(nèi)存巨大，其內(nèi)存對象數(shù)量極多，GC完成一次回收周期，可能需要數(shù)秒甚至更長時間，這段時間內(nèi)，整個服務(wù)進(jìn)程是阻塞的、停頓的，在外界看來就是服務(wù)中斷、無響應(yīng)，再牛逼的并發(fā)機(jī)制到了這里統(tǒng)統(tǒng)失效。垃圾回收器定期啟動，每次啟動就導(dǎo)致短暫的服務(wù)中斷，這樣下去，還有人敢用嗎？這可是后臺服務(wù)器進(jìn)程，是Go語言的重點(diǎn)應(yīng)用領(lǐng)域。以上現(xiàn)象可不是我假設(shè)出來的，而是事實(shí)存在的現(xiàn)實(shí)問題，受其嚴(yán)重困擾的也不是一家兩家了（2013年底ECUG Con 2013，京東的劉奇提到了Go語言的GC、defer、標(biāo)準(zhǔn)庫實(shí)現(xiàn)是性能殺手，最大的痛苦是GC；美團(tuán)的沈鋒也提到Go語言的GC導(dǎo)致后臺服務(wù)間隔性停頓是最大的問題。更早的網(wǎng)絡(luò)游戲仙俠道開發(fā)團(tuán)隊也曾受Go垃圾回收的沉重打擊）。在實(shí)踐中，你必須努力減少進(jìn)程中的對象數(shù)量，以便把GC導(dǎo)致的間歇性停頓控制在可接受范圍內(nèi)。除此之外你別無選擇（難道你還想自己更換GC算法、甚至砍掉GC？那還是Go語言嗎？）。跳出圈外，我近期一直在思考，一定需要垃圾回收器嗎？沒有垃圾回收器就一定是歷史的倒退嗎？（可能會新寫一篇博客文章專題探討。）
這是說的是32位系統(tǒng), 這絕對不是Go語言的重點(diǎn)應(yīng)用領(lǐng)域!! 我可以說Go出生就是面向64位系統(tǒng)和多核心CPU環(huán)境設(shè)計的. (再說 Rust 目前好像還不支持 XP 吧, 這可不可以算是影響巨大?)
32位當(dāng)時是有問題, 但是對實(shí)際生產(chǎn)影響并不大(請問樓主還是在用32位系統(tǒng)嗎, 還只安裝4GB的內(nèi)存嗎). 如果是8位單片機(jī)環(huán)境, 建議就不要用Go語言了, 直接C語言好了.
而且這個問題早就不存在了(大家可以去看Go的發(fā)布日志).
Go的出生也就5年時間, GC的完善和改進(jìn)是一個持續(xù)的工作, 2015年8月將發(fā)布的 Go1.5將采用并行GC.
關(guān)于GC的被人詬病的地方是會導(dǎo)致卡頓, 但是我以為這個主要是因為GC的實(shí)現(xiàn)還不夠完美而導(dǎo)致的.
如果是完美的并發(fā)和增量的GC, 那應(yīng)該不會出現(xiàn)大的卡頓問題的.
當(dāng)然, 如果非要實(shí)時性, 那用C好了(實(shí)時并不表示性能高, 只是響應(yīng)時間可控).
對于Rust之類沒有GC的語言來說, 想很方便的開發(fā)并發(fā)的后臺程序那幾乎是不可能的.
不要總是吹Rust能代替底層/中層/上層的開發(fā), 我們要看有誰用Rust真的做了什么.
1.6 禁止未使用變量和多余import
Go編譯器不允許存在被未被使用的變量和多余的import，如果存在，必然導(dǎo)致編譯錯誤。但是現(xiàn)實(shí)情況是，在代碼編寫、重構(gòu)、調(diào)試過程中，例如，臨時性的注釋掉一行代碼，很容易就會導(dǎo)致同時出現(xiàn)未使用的變量和多余的import，直接編譯錯誤了，你必須相應(yīng)的把變量定義注釋掉，再翻頁回到文件首部把多余的import也注釋掉，……等事情辦完了，想把剛才注釋的代碼找回來，又要好幾個麻煩的步驟。還有一個讓人蛋疼的問題，編寫數(shù)據(jù)庫相關(guān)的代碼時，如果你import某數(shù)據(jù)庫驅(qū)動的pkg，它編譯給你報錯，說不需要import這個未被使用的pkg；但如果你聽信編譯器的話刪掉該import，編譯是通過了，運(yùn)行時必然報錯，說找不到數(shù)據(jù)庫驅(qū)動；你看看程序員被折騰的兩邊不是人，最后不得不請出大神：import _。對待這種問題，一個比較好的解決方案是，視其為編譯警告而非編譯錯誤。但是Go語言開發(fā)者很固執(zhí)，不容許這種折中方案。
這個問題我只能說樓主的吐槽真的是沒水平.
為何不使用的是錯誤而不是警告? 這是為了將低級的bug消滅在編譯階段(大家可以想下C/C++的那么多警告有什么卵用).
而且, import 即使沒有使用的話, 也是用副作用的, 因為 import 會導(dǎo)致 init 和全局變量的初始化.
如果某些代碼沒有使用, 為何要執(zhí)行 init 這些初始化呢?
如果是因為調(diào)試而添加的變量, 那么調(diào)試完刪除不是很正常的要求嗎?
如果是因為調(diào)試而要導(dǎo)入fmt或log之類的包, 刪除調(diào)試代碼后又導(dǎo)致 import 錯誤的花,
樓主難道不知道在一個獨(dú)立的文件包裝下類似的輔助調(diào)試的函數(shù)嗎?
import (
"fmt"
"log"
)
func logf(format string, a ...interface{}) {
file, line := callerFileLine()
fmt.Fprintf(os.Stderr, "%s:%d: ", file, line)
fmt.Fprintf(os.Stderr, format, a...)
}
func fatalf(format string, a ...interface{}) {
file, line := callerFileLine()
fmt.Fprintf(os.Stderr, "%s:%d: ", file, line)
fmt.Fprintf(os.Stderr, format, a...)
os.Exit(1)
}
import _ 是有明確行為的用法, 就是為了執(zhí)行包中的 init 等函數(shù)(可以做某些注冊操作).
將警告當(dāng)作錯誤是Go的一個哲學(xué), 當(dāng)然在樓主看來這是白癡做法.
1.7 創(chuàng)建對象的方式太多令人糾結(jié)
創(chuàng)建對象的方式，調(diào)用new函數(shù)、調(diào)用make函數(shù)、調(diào)用New方法、使用花括號語法直接初始化結(jié)構(gòu)體，你選哪一種？不好選擇，因為沒有一個固定的模式。從實(shí)踐中看，如果要創(chuàng)建一個語言內(nèi)置類型（如channel、map）的對象，通常用make函數(shù)創(chuàng)建；如果要創(chuàng)建標(biāo)準(zhǔn)庫或第三方庫定義的類型的對象，首先要去文檔里找一下有沒有New方法，如果有就最好調(diào)用New方法創(chuàng)建對象，如果沒有New方法，則退而求其次，用初始化結(jié)構(gòu)體的方式創(chuàng)建其對象。這個過程頗為周折，不像C++、Java、C#那樣直接new就行了。
C++的new是狗屎. new導(dǎo)致的問題是構(gòu)造函數(shù)和普通函數(shù)的行為不一致, 這個補(bǔ)丁特性真的沒啥優(yōu)越的.
我還是喜歡C語言的 fopen 和 malloc 之類構(gòu)造函數(shù), 構(gòu)造函數(shù)就是普通函數(shù), Go語言中也是這樣.
C++中, 除了構(gòu)造不兼容普通函數(shù), 析構(gòu)函數(shù)也是不兼容普通函數(shù). 這個而引入的坑有很多吧.
1.8 對象沒有構(gòu)造函數(shù)和析構(gòu)函數(shù)
沒有構(gòu)造函數(shù)還好說，畢竟還有自定義的New方法，大致也算是構(gòu)造函數(shù)了。沒有析構(gòu)函數(shù)就比較難受了，沒法實(shí)現(xiàn)RAII。額外的人工處理資源清理工作，無疑加重了程序員的心智負(fù)擔(dān)。沒人性啊，還嫌我們程序員加班還少嗎？C++里有析構(gòu)函數(shù)，Java里雖然沒有析構(gòu)函數(shù)但是有人家finally語句啊，Go呢，什么都沒有。沒錯，你有個defer，可是那個defer問題更大，詳見下文吧。
defer 可以覆蓋析構(gòu)函數(shù)的行為, 當(dāng)然 defer 還有其他的任務(wù). Swift2.0 也引入了一個簡化版的 defer 特性.
1.9 defer語句的語義設(shè)定不甚合理
Go語言設(shè)計defer語句的出發(fā)點(diǎn)是好的，把釋放資源的“代碼”放在靠近創(chuàng)建資源的地方，但把釋放資源的“動作”推遲（defer）到函數(shù)返回前執(zhí)行。遺憾的是其執(zhí)行時機(jī)的設(shè)置似乎有些不甚合理。設(shè)想有一個需要長期運(yùn)行的函數(shù)，其中有無限循環(huán)語句，在循環(huán)體內(nèi)不斷的創(chuàng)建資源（或分配內(nèi)存），并用defer語句確保釋放。由于函數(shù)一直運(yùn)行沒有返回，所有defer語句都得不到執(zhí)行，循環(huán)過程中創(chuàng)建的大量短暫性資源一直積累著，得不到回收。而且，系統(tǒng)為了存儲defer列表還要額外占用資源，也是持續(xù)增加的。這樣下去，過不了多久，整個系統(tǒng)就要因為資源耗盡而崩潰。像這類長期運(yùn)行的函數(shù)，http.ListenAndServe()就是典型的例子。在Go語言重點(diǎn)應(yīng)用領(lǐng)域，可以說幾乎每一個后臺服務(wù)程序都必然有這么一類函數(shù)，往往還都是程序的核心部分。如果程序員不小心在這些函數(shù)中使用了defer語句，可以說后患無窮。如果語言設(shè)計者把defer的語義設(shè)定為在所屬代碼塊結(jié)束時（而非函數(shù)返回時）執(zhí)行，是不是更好一點(diǎn)呢？可是Go 1.0早已發(fā)布定型，為了保持向后兼容性，已經(jīng)不可能改變了。小心使用defer語句！一不小心就中招。
前面說到 defer 還有其他的任務(wù), 也就是 defer 中執(zhí)行的 recover 可以捕獲 panic 拋出的異常.
還有 defer 可以在 return 之后修改命名的返回值.
上面2個工作要求 defer 只能在函數(shù)退出時來執(zhí)行.
樓主說的 defer 是類似 Swift2.0 中 defer 的行為, 但是 Swift2.0 中 defer 是沒有前面2個特性的.
Go中的defer是以函數(shù)作用域作為觸發(fā)的條件的, 是會導(dǎo)致樓主說的在 for 中執(zhí)行的錯誤用法(哪個語言沒有坑呢?).
不過 for 中 局部 defer 也是有辦法的 (Go中的defer是以函數(shù)作用域):
for {
func(){
f, err := os.Open(...)
defer f.Close()
}()
}
在 for 中做一個閉包函數(shù)就可以了. 自己不會用不要怪別人沒告訴你.
1.10 許多語言內(nèi)置設(shè)施不支持用戶定義的類型
for in、make、range、channel、map等都僅支持語言內(nèi)置類型，不支持用戶定義的類型(?)。用戶定義的類型沒法支持for in循環(huán)，用戶不能編寫像make、range那樣“參數(shù)類型和個數(shù)”甚至“返回值類型和個數(shù)”都可變的函數(shù)，不能編寫像channel、map那樣類似泛型的數(shù)據(jù)類型。語言內(nèi)置的那些東西，處處充斥著斧鑿的痕跡。這體現(xiàn)了語言設(shè)計的局限性、封閉性、不完善，可擴(kuò)展性差，像是新手作品——且不論其設(shè)計者和實(shí)現(xiàn)者如何權(quán)威。延伸閱讀：Go語言是30年前的陳舊設(shè)計思想，用戶定義的東西幾乎都是二等公民（Tikhon Jelvis）。
說到底, 這個是因為對泛型支持的不完備導(dǎo)致的.
Go語言是沒啥NB的特性, 但是Go的特性和工具組合在一起就是好用.
這就是Go語言NB的地方.
1.11 沒有泛型支持，常見數(shù)據(jù)類型接口丑陋
沒有泛型的話，List、Set、Tree這些常見的基礎(chǔ)性數(shù)據(jù)類型的接口就只能很丑陋：放進(jìn)去的對象是一個具體的類型，取出來之后成了無類型的interface{}（可以視為所有類型的基礎(chǔ)類型），還得強(qiáng)制類型轉(zhuǎn)換之后才能繼續(xù)使用，令人無語。Go語言缺少min、max這類函數(shù)，求數(shù)值絕對值的函數(shù)abs只接收/返回雙精度小數(shù)類型，排序接口只能借助sort.Interface無奈的回避了被比較對象的類型，等等等等，都是沒有泛型導(dǎo)致的結(jié)果。沒有泛型，接口很難優(yōu)雅起來。Go開發(fā)者沒有明確拒絕泛型，只是說還沒有找到很好的方法實(shí)現(xiàn)泛型（能不能學(xué)學(xué)已經(jīng)開源的語言呀）?，F(xiàn)實(shí)是，Go 1.0已經(jīng)定型，泛型還沒有，那些丑陋的接口為了保持向后兼容必須長期存在著。
Go有自己的哲學(xué), 如果能有和目前哲學(xué)不沖突的泛型實(shí)現(xiàn), 他們是不會反對的.
如果只是簡單學(xué)學(xué)(或者叫抄襲)已經(jīng)開源的語言的語法, 那是C++的設(shè)計風(fēng)格(或者說C++從來都是這樣設(shè)計的, 有什么特性就抄什么), 導(dǎo)致了各種腦裂的編程風(fēng)格.
編譯時泛型和運(yùn)行時泛型可能是無法完全兼容的, 看這個例子:
type AdderT interface {
Add(a, b T) T
}
重慶分公司
重慶分公司
