為什么要使用 Go 語言？Go 語言的優(yōu)勢在哪里

1. 保留但大幅度簡化指針

創(chuàng)新互聯(lián)是專業(yè)的鏡湖網(wǎng)站建設公司，鏡湖接單;提供成都做網(wǎng)站、成都網(wǎng)站建設、成都外貿(mào)網(wǎng)站建設,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行鏡湖網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

Go語言保留著C中值和指針的區(qū)別，但是對于指針繁瑣用法進行了大量的簡化，引入引用的概念。所以在Go語言中，你幾乎不用擔心會因為直接操作內(nèi)寸而引起各式各樣的錯誤。

2. 多參數(shù)返回

還記得在C里面為了回饋多個參數(shù)，不得不開辟幾段指針傳到目標函數(shù)中讓其操作么？在Go里面這是完全不必要的。而且多參數(shù)的支持讓Go無需使用繁瑣的exceptions體系，一個函數(shù)可以返回期待的返回值加上error，調(diào)用函數(shù)后立刻處理錯誤信息，清晰明了。

3. Array，slice，map等內(nèi)置基本數(shù)據(jù)結構

如果你習慣了Python中簡潔的list和dict操作，在Go語言中，你不會感到孤單。一切都是那么熟悉，而且更加高效。如果你是C++程序員，你會發(fā)現(xiàn)你又找到了STL的vector 和 map這對朋友。

4. Interface

Go語言最讓人贊嘆不易的特性，就是interface的設計。任何數(shù)據(jù)結構，只要實現(xiàn)了interface所定義的函數(shù)，自動就implement了這個interface，沒有像Java那樣冗長的class申明，提供了靈活太多的設計度和OO抽象度，讓你的代碼也非常干凈。千萬不要以為你習慣了Java那種一條一條加implements的方式，感覺還行，等接口的設計越來越復雜的時候，無數(shù)Bug正在后面等著你。

同時，正因為如此，Go語言的interface可以用來表示任何generic的東西，比如一個空的interface，可以是string可以是int，可以是任何數(shù)據(jù)類型，因為這些數(shù)據(jù)類型都不需要實現(xiàn)任何函數(shù)，自然就滿足空interface的定義了。加上Go語言的type assertion，可以提供一般動態(tài)語言才有的duck typing特性， 而仍然能在compile中捕捉明顯的錯誤。

5. OO

Go語言本質上不是面向對象語言，它還是過程化的。但是，在Go語言中， 你可以很輕易的做大部分你在別的OO語言中能做的事，用更簡單清晰的邏輯。是的，在這里，不需要class，仍然可以繼承，仍然可以多態(tài)，但是速度卻快得多。因為本質上，OO在Go語言中，就是普通的struct操作。

6. Goroutine

這個幾乎算是Go語言的招牌特性之一了，我也不想多提。如果你完全不了解Goroutine，那么你只需要知道，這玩意是超級輕量級的類似線程的東西，但通過它，你不需要復雜的線程操作鎖操作，不需要care調(diào)度，就能玩轉基本的并行程序。在Go語言里，觸發(fā)一個routine和erlang spawn一樣簡單。基本上要掌握Go語言，以Goroutine和channel為核心的內(nèi)存模型是必須要懂的。不過請放心，真的非常簡單。

7. 更多現(xiàn)代的特性

和C比較，Go語言完全就是一門現(xiàn)代化語言，原生支持的Unicode, garbage collection, Closures(是的，和functional programming language類似), function是first class object，等等等等。

看到這里，你可能會發(fā)現(xiàn)，我用了很多輕易，簡單，快速之類的形容詞來形容Go語言的特點。我想說的是，一點都不夸張，連Go語言的入門學習到提高，都比別的語言門檻低太多太多。在大部分人都有C的背景的時代，對于Go語言，從入門到能夠上手做項目，最多不過半個月。Go語言給人的感覺就是太直接了，什么都直接，讀源代碼直接，寫自己的代碼也直接。

從PHP 到Golang 的筆記 ( 轉 )

———文章來源 YamiOdymel/PHP-to-Golang

PHP和模塊之間的關系令人感到煩躁，假設你要讀取 yaml 檔案，你需要有一個 yaml 的模塊，為此，你還需要將其編譯然后將編譯后的模塊擺放至指定位置，之后換了一臺伺服器你還要重新編譯，這點到現(xiàn)在還是沒有改善；順帶一提之后出了PHP 7效能確實提升了許多（比Python 3快了些），但PHP仍令我感到臃腫，我覺得是時候

（轉行）了。

PHP 和Golang 的效能我想毋庸置疑是后者比較快（而且是以倍數(shù)來算），也許有的人會認為兩種不應該被放在一起比較，但Golang 本身就是偏向Web 開發(fā)的，所以這也是為什么我考慮轉用Golang 的原因，起初我的考慮有幾個：Node.js 和Rust 還有最終被選定的Golang；先談談Node.js 吧。

Node.js的效能可以說是快上PHP 3.5倍至6倍左右 ，而且撰寫的語言還是JavaScript，蒸蚌，如此一來就不需要學習新語言了！搭配Babel更可以說是萬能，不過那跟「跳跳虎」一樣的Async邏輯還有那恐怖的Callback Hell，有人認為前者是種優(yōu)點，這點我不否認，但是對學習PHP的我來說太過于"Mind Fuck"，至于后者的Callback Hell雖然有Promise，但是那又是另一個「Then Hell」的故事了。相較于Golang之下，Node.js似乎就沒有那么吸引我了。你確實可以用Node.js寫出很多東西，不過那V8引擎的效能仍然有限，而且要學習新的事物，不就應該是「全新」的嗎;)？

題外話： 為什么Node.js不適合大型和商業(yè)專案？

在拋棄改用Node.js 之后我曾經(jīng)花了一天的時間嘗試Rust 和Iron 框架，嗯??Rust 太強大了，強大到讓我覺得Rust 不應該用在這里，這想法也許很蠢，但Rust 讓我覺得適合更應該拿來用在系統(tǒng)或者是部分底層的地方，而不應該是網(wǎng)路服務。

Golang是我最終的選擇，主要在于我花了一天的時間來研究的時候意外地發(fā)現(xiàn)Golang夭壽簡潔（ 關鍵字只有25個 ），相較之下Rust太過于「強大」令我怯步；而且Golang帶有許多工具，例如 go fmt 會自動幫你整理程式碼、 go doc 會自動幫你生產(chǎn)文件、 go test 可以自動單元測試并生產(chǎn)覆蓋率報表、也有 go get 套件管理工具（雖然沒有版本功能），不過都很實用，而且也不需要加上分號（ ; ），真要說不好的地方??大概就是強迫你花括號不能換行放吧（沒錯，我就是花括號會換行放的人）。

當我在撰寫這份文件的時候 我會先假設你有一定的基礎 ，你可以先閱讀下列的手冊，他們都很不錯。

你能夠在PHP 里面想建立一個變數(shù)的時候就直接建立，夭壽贊，是嗎？

蒸蚌！那么Golang 呢？在Golang 中變數(shù)分為幾類：「新定義」、「預先定義」、「自動新定義」、「覆蓋」。讓我們來看看范例：

在PHP中你會很常用到 echo 來顯示文字，像這樣。

然而在Golang中你會需要 fmt 套件，關于「什么是套件」的說明你可以在文章下述了解。

這很簡單，而且兩個語言的用法相差甚少，下面這是PHP：

只是Golang 稍微聒噪了一點，你必須在函式后面宣告他最后會回傳什么資料型別。

在PHP 中你要回傳多個資料你就會用上陣列，然后將資料放入陣列里面，像這樣。

然而在Golang 中你可以不必用到一個陣列，函式可以一次回傳多個值：

兩個語言的撰寫方式不盡相同。

主要是PHP 的陣列能做太多事情了，所以在PHP 里面要儲存什么用陣列就好了。

在Golang里??沒有這么萬能的東西，首先要先了解Golang中有這些型態(tài)： array , slice , map , interface ，

你他媽的我到底看了三洨，首先你要知道Golang是個強型別語言，意思是你的陣列中 只能有一種型態(tài) ，什么意思？當你決定這個陣列是用來擺放字串資料的時候，你就只能在里面放字串。沒有數(shù)值、沒有布林值，就像你沒有女朋友一樣。

先撇開PHP 的「萬能陣列」不管，Golang 中的陣列既單純卻又十分腦殘，在定義一個陣列的時候，你必須給他一個長度還有其內(nèi)容存放的資料型態(tài)，你的陣列內(nèi)容不一定要填滿其長度，但是你的陣列內(nèi)容不能超過你當初定義的長度。

切片??這聽起來也許很奇怪，但是你確實可以「切」他，讓我們先談談「切片」比起「陣列」要好在哪里：「你不用定義其最大長度，而且你可以直接賦予值」，沒了。

我們剛才有提到你可以「切」他，記得嗎？這有點像是PHP中的 array_slice() ，但是Golang直接讓Slice「內(nèi)建」了這個用法，其用法是： slice[開始:結束] 。

在PHP中倒是沒有那么方便，在下列PHP范例中你需要不斷地使用 array_slice() 。

你可以把「映照」看成是一個有鍵名和鍵值的陣列，但是記住：「你需要事先定義其鍵名、鍵值的資料型態(tài)」，這仍限制你沒辦法在映照中存放多種不同型態(tài)的資料。

在Golang里可就沒這么簡單了，你需要先用 make() 宣告 map 。

也許你不喜歡「接口」這個詞，但用「介面」我怕會誤導大眾，所以，是的，接下來我會繼續(xù)稱其為「接口」。還記得你可以在PHP 的關聯(lián)陣列里面存放任何型態(tài)的資料嗎，像下面這樣？

現(xiàn)在你有福了！正因為Golang中的 interface{} 可以接受任何內(nèi)容，所以你可以把它拿來存放任何型態(tài)的資料。

有時候你也許會有個不定值的變數(shù)，在PHP 里你可以直接將一個變數(shù)定義成字串、數(shù)值、空值、就像你那變心的女友一樣隨時都在變。

在Golang中你必須給予變數(shù)一個指定的資料型別，不過還記得剛才提到的：「Golang中有個 interface{} 能夠 存放任何事物 」嗎（ 雖然也不是真的任何事物啦?? ）？

當我們程式中不需要繼續(xù)使用到某個資源或是發(fā)生錯誤的時候，我們索性會將其關閉或是拋棄來節(jié)省資源開銷，例如PHP 里的讀取檔案：

在Golang中，你可以使用 defer 來在函式結束的時候自動執(zhí)行某些程式(其執(zhí)行方向為反向)。所以你就不需要在函式最后面結束最前面的資源。

defer 可以被稱為「推遲執(zhí)行」，實際上就是在函式結束后會「反序」執(zhí)行的東西，例如你按照了這樣的順序定義 defer ： A-B-C-D ，那么執(zhí)行的順序其實會是 D-C-B-A ，這用在程式結束時還蠻有用的，讓我們看看Golang如何改善上述范例。

這東西很邪惡，不是嗎？又不是在寫B(tài)ASIC，不過也許有時候你會在PHP 用上呢。但是拜托，不要。

Golang中僅有 for 一種回圈但卻能夠達成 foreach 、 while 、 for 多種用法。普通 for 回圈寫法在兩個語言中都十分相近。

在Golang請記得：如果你的 i 先前并不存在，那么你就需要定義它，所以下面這個范例你會看見 i := 0 。

在PHP里， foreach() 能夠直接給你值和鍵名，用起來十分簡單。

Golang里面雖然僅有 for() 但卻可以使用 range 達成和PHP一樣的 foreach 方式。

一個 while(條件) 回圈在PHP里面可以不斷地執(zhí)行區(qū)塊中的程式，直到 條件 為 false 為止。

在Golang里也有相同的做法，但仍是透過 for 回圈，請注意這個 for 回圈并沒有任何的分號（ ; ），而且一個沒有條件的 for 回圈會一直被執(zhí)行。

PHP中有 do .. while() 回圈可以先做區(qū)塊中的動作。

在Golang中則沒有相關函式，但是你可以透過一個無止盡的 for 回圈加上條件式來讓他結束回圈。

要是你真的希望完全符合像是PHP那樣的設計方式，或者你可以在Golang中使用很邪惡的 goto 。

在PHP中我們可以透過 date() 像這樣取得目前的日期。

在Golang就稍微有趣點了，因為Golang中并不是以 Y-m-d 這種格式做為定義，而是 1 、 2 、 3 ，這令你需要去翻閱文件，才能夠知道 1 的定義是代表什么。

俗話說：「爆炸就是藝術」，可愛的PHP用詞真的很大膽，像是： explode() （爆炸）、 die() （死掉），回歸正傳，如果你想在PHP里面將字串切割成陣列，你可以這么做。

簡單的就讓一個字串給「爆炸」了，那么Golang 呢？

對了，記得引用 strings 套件。

這真的是很常用到的功能，就像物件一樣有著鍵名和鍵值，在PHP 里面你很簡單的就能靠陣列（Array）辦到。

真是太棒了，那么Golang呢？用 map 是差不多啦。如果有必要的話，你可以稍微復習一下先前提到的「多資料儲存型態(tài)－Stores」。

你很常會在PHP里面用 isset() 檢查一個索引是否存在，不是嗎？

在Golang里面很簡單的能夠這樣辦到（僅適用于 map ）。

指針（有時也做參照）是一個像是「變數(shù)別名」的方法，這種方法讓你不用整天覆蓋舊的變數(shù)，讓我們假設 A = 1; B = A; 這個時候 B 會復制一份 A 且兩者不相干，倘若你希望修改 B 的時候實際上也會修改到 A 的值，就會需要指針。

指針比起復制一個變數(shù)，他會建立一個指向到某個變數(shù)的記憶體位置，這也就是為什么你改變指針，實際上是在改變某個變數(shù)。

在Golang你需要用上 * 還有 符號。

有些時候你會回傳一個陣列，這個陣列里面可能有資料還有錯誤代號，而你會用條件式判斷錯誤代號是否非空值。

在Golang中函式可以一次回傳多個值。為此，你不需要真的回傳一個陣列，不過要注意的是你將會回傳一個屬于 error 資料型態(tài)的錯誤，所以你需要引用 errors 套件來幫助你做這件事。

該注意的是Golang沒有 try .. catch ，因為 Golang推薦這種錯誤處理方式 ，你應該在每一次執(zhí)行可能會發(fā)生錯誤的程式時就處理錯誤，而非后來用 try 到處包覆你的程式。

在 if 條件式里宣告變數(shù)會讓你只能在 if 內(nèi)部使用這個變數(shù)，而不會污染到全域范圍。

也許你在PHP中更常用的會是 try .. catch ，在大型商業(yè)邏輯時經(jīng)常看見如此地用法，實際上這種用法令人感到聒噪（因為你會需要一堆 try 區(qū)塊）：

Golang中并沒有 try .. catch ，實際上Golang也 不鼓勵這種行為 （Golang推薦逐一處理錯誤的方式），倘若你真想辦倒像是捕捉異常這樣的方式，你確實可以使用Golang中另類處理錯誤的方式（可以的話盡量避免使用這種方式）： panic() , recover() , defer 。

你可以把 panic() 當作是 throw （丟出錯誤），而這跟PHP的 exit() 有87%像，一但你執(zhí)行了 panic() 你的程式就會宣告而終，但是別擔心，因為程式結束的時候會呼叫 defer ，所以我們接下來要在 defer 停止 panic() 。

關于 defer 上述已經(jīng)有提到了，他是一個反向執(zhí)行的宣告，會在函式結束后被執(zhí)行，當你呼叫了 panic() 結束程式的時候，也就會開始執(zhí)行 defer ，所以我們要在 defer 內(nèi)使用 recover() 讓程式不再繼續(xù)進行結束動作，這就像是捕捉異常。

recover() 可以看作 catch （捕捉），我們要在 defer 里面用 recover() 解決 panic() ，如此一來程式就會回歸正常而不會被結束。

還記得在PHP里要引用一堆檔案的日子嗎？到處可見的 require() 或是 include() ？到了Golang這些都不見了，取而代之的是「套件（Package）」。現(xiàn)在讓我們來用PHP解釋一下。

這看起來很正常對吧？但假設你有一堆檔案，這馬上就成了 Include Hell ，讓我們看看Golang怎么透過「套件」解決這個問題。

「 蛤？？？殺小？？？ 」你可能如此地說道。是的， main.go 中除了引用 fmt 套件（ 為了要輸出結果用的套件 ）之外完全沒有引用到 a.go 。

「 蛤？？？殺小？？？？？？ 」你仿佛回到了幾秒鐘前的自己。

既然沒有引用其他檔案，為什么 main.go 可以輸出 foo 呢？注意到了嗎， 兩者都是屬于 main 套件 ，因此 他們共享同一個區(qū)域 ，所以接下來要介紹的是什么叫做「套件」。

套件是每一個 .go 檔案都必須聲明在Golang原始碼中最開端的東西，像下面這樣：

這意味著目前的檔案是屬于 main 套件（ 你也可以依照你的喜好命名 ），那么要如何讓同個套件之間的函式溝通呢？

接著是Golang；注意！你不需要引用任何檔案，因為下列兩個檔案同屬一個套件。

一個由「套件」所掌握的世界，比起PHP的 include() 和 require() 還要好太多了，對嗎？

在Golang 中沒有引用單獨檔案的方式，你必須匯入一整個套件，而且你要記住：「一定你匯入了，你就一定要使用它」，像下面這樣。

假如你不希望使用你匯入的套件，你只是為了要觸發(fā)那個套件的 main() 函式而引用的話??，那么你可以在前面加上一個底線（ _ ）。

如果你的套件出現(xiàn)了名稱沖突，你可以在套件來源前面給他一個新的名稱。

現(xiàn)在你知道可以匯入套件了，那么什么是「匯出」？同個套件內(nèi)的函式還有共享變數(shù)確實可以直接用，但那 并不表示可以給其他套件使用 ，其方法取決于 函式／變數(shù)的「開頭大小寫」 。

是的。 Golang依照一個函式／變數(shù)的開頭大小寫決定這個東西是否可供「匯出」 。

這用在區(qū)別函式的時候格外有用，因為小寫開頭的任何事物都是不供匯出的，反之，大寫開頭的任何事物都是用來匯出供其他套件使用的。

一開始可能會覺得這是什么奇異的規(guī)定，但寫久之后，你就能發(fā)現(xiàn)比起JavaScript和Python以「底線為開頭的命名方式」還要來得更好；比起成天宣告 public 、 private 、 protected 還要來得更快。

在Golang 中沒有類別，但有所謂的「建構體（Struct）」和「接口（Interface）」，這就能夠滿足幾乎所有的需求了，這也是為什么我認為Golang 很簡潔卻又很強大的原因。

讓我們先用PHP 建立一個類別，然后看看Golang 怎么解決這個問題。

雖然Golang沒有類別，但是「建構體（Struct）」就十分地堪用了，首先你要知道在Golang中「類別」的成員還有方法都是在「類別」外面所定義的，這跟PHP在類別內(nèi)定義的方式有所不同，在Golang中還有一點，那就是他們沒有 public 、 private 、 protected 的種類。

在PHP中，當有一個類別被 new 的時候會自動執(zhí)行該類別內(nèi)的建構子（ __construct() ），通常你會用這個來初始化一些類別內(nèi)部的值。

但是在Golang 里因為沒有類別，也就沒有建構子，不巧的是建構體本身也不帶有建構子的特性，這個時候你只能自己在外部建立一個建構用函式。

讓我們假設你有兩個類別，你會把其中一個類別傳入到另一個類別里面使用，廢話不多說！先上個PHP 范例（為了簡短篇幅我省去了換行）。

在Golang中你也有相同的用法，但是請記得：「 任何東西都是在「類別」外完成建構的 」。

在PHP 中沒有相關的范例，這部分會以剛才「嵌入」章節(jié)中的Golang 范例作為解說對象。

你可以看見Golang在進行 Foo 嵌入 Bar 的時候，會自動將 Foo 的成員暴露在 Bar 底下，那么假設「雙方之間有相同的成員名稱」呢？

這個時候被嵌入的成員就會被「遮蔽」，下面是個實際范例，還有你如何解決遮蔽問題：

雖然都是呼叫同一個函式，但是這個函式可以針對不同的資料來源做出不同的舉動，這就是多形。你也能夠把這看作是：「訊息的意義由接收者定義，而不是傳送者」。

目前PHP 中沒有真正的「多形」，不過你仍可以做出同樣的東西。

嗯??那么Golang呢？實際上更簡單而且更有條理了，在Golang中有 interface 可以幫忙完成這個工作。

如果你對Interface還不熟悉，可以試著查看「 解釋Golang中的Interface到底是什么 」文章。

謝謝你看到這里，可惜這篇文章卻沒有說出Golang 最重要的賣點：「Goroutine」和「Channel」

Go 語言的錯誤處理機制是一個優(yōu)秀的設計嗎

這個問題說來話長，我先表達一下我的觀點，Go語言從語法層面提供區(qū)分錯誤和異常的機制是很好的做法，比自己用單個返回值做值判斷要方便很多。

上面看到很多知乎大牛把異常和錯誤混在一起說，有認為Go沒有異常機制的，有認為Go純粹只有異常機制的，我覺得這些觀點都太片面了。

具體對于錯誤和異常的討論，我轉發(fā)一下前陣子寫的一篇日志拋磚引玉吧。

============================

最近連續(xù)遇到朋友問我項目里錯誤和異常管理的事情，之前也多次跟團隊強調(diào)過錯誤和異常管理的一些概念，所以趁今天有動力就趕緊寫一篇Go語言項目錯誤和異常管理的經(jīng)驗分享。

首先我們要理清：什么是錯誤、什么是異常、為什么需要管理。然后才是怎樣管理。

錯誤和異常從語言機制上面講，就是error和panic的區(qū)別，放到別的語言也一樣，別的語言沒有error類型，但是有錯誤碼之類的，沒有panic，但是有throw之類的。

在語言層面它們是兩種概念，導致的是兩種不同的結果。如果程序遇到錯誤不處理，那么可能進一步的產(chǎn)生業(yè)務上的錯誤，比如給用戶多扣錢了，或者進一步產(chǎn)生了異常；如果程序遇到異常不處理，那么結果就是進程異常退出。

在項目里面是不是應該處理所有的錯誤情況和捕捉所有的異常呢？我只能說，你可以這么做，但是估計效果不會太好。我的理由是：

如果所有東西都處理和記錄，那么重要信息可能被淹沒在信息的海洋里。

不應該處理的錯誤被處理了，很容易導出BUG暴露不出來，直到出現(xiàn)更嚴重錯誤的時候才暴露出問題，到時候排查就很困難了，因為已經(jīng)不是錯誤的第一現(xiàn)場。

所以錯誤和異常最好能按一定的規(guī)則進行分類和管理，在第一時間能暴露錯誤和還原現(xiàn)場。

對于錯誤處理，Erlang有一個很好的概念叫速錯，就是有錯誤第一時間暴露它。我們的項目從Erlang到Go一直是沿用這一設計原則。但是應用這個原則的前提是先得區(qū)分錯誤和異常這兩個概念。

錯誤和異常上面已經(jīng)提到了，從語言機制層面比較容易區(qū)分它們，但是語言取決于人為，什么情況下用錯誤表達，什么情況下用異常表達，就得有一套規(guī)則，否則很容易出現(xiàn)全部靠異常來做錯誤處理的情況，似乎Java項目特別容易出現(xiàn)這樣的設計。

這里我先假想有這樣一個業(yè)務：游戲玩家通過購買按鈕，用銅錢購買寶石。

在實現(xiàn)這個業(yè)務的時候，程序邏輯會進一步分化成客戶端邏輯和服務端邏輯，客戶端邏輯又進一步因為設計方式的不同分化成兩種結構：胖客戶端結構、瘦客戶端結構。

胖客戶端結構，有更多的本地數(shù)據(jù)和懂得更多的業(yè)務邏輯，所以在胖客戶端結構的應用中，以上的業(yè)務會實現(xiàn)成這樣：客戶端檢查緩存中的銅錢數(shù)量，銅錢數(shù)量足夠的時候購買按鈕為可用的亮起狀態(tài)，用戶點擊購買按鈕后客戶端發(fā)送購買請求到服務端；服務端收到請求后校驗用戶的銅錢數(shù)量，如果銅錢數(shù)量不足就拋出異常，終止請求過程并斷開客戶端的連接，如果銅錢數(shù)量足夠就進一步完成寶石購買過程，這里不繼續(xù)描述正常過程。

因為正常的客戶端是有一步數(shù)據(jù)校驗的過程的，所以當服務端收到不合理的請求（銅錢不足以購買寶石）時，拋出異常比返回錯誤更為合理，因為這個請求只可能來自兩種客戶端：外掛或者有BUG的客戶端。如果不通過拋出異常來終止業(yè)務過程和斷開客戶端連接，那么程序的錯誤就很難被第一時間發(fā)現(xiàn)，攻擊行為也很難被發(fā)現(xiàn)。

我們再回頭看瘦客戶端結構的設計，瘦客戶端不會存有太多狀態(tài)數(shù)據(jù)和用戶數(shù)據(jù)也不清楚業(yè)務邏輯，所以客戶端的設計會是這樣：用戶點擊購買按鈕，客戶端發(fā)送購買請求；服務端收到請求后檢查銅錢數(shù)量，數(shù)量不足就返回數(shù)量不足的錯誤碼，數(shù)量足夠就繼續(xù)完成業(yè)務并返回成功信息；客戶端收到服務端的處理結果后，在界面上做出反映。

在這種結構下，銅錢不足就變成了業(yè)務邏輯范圍內(nèi)的一種失敗情況，但不能提升為異常，否則銅錢不足的用戶一點購買按鈕都會出錯掉線。

所以，異常和錯誤在不同程序結構下是互相轉換的，我們沒辦法一句話的給所有類型所有結構的程序一個統(tǒng)一的異常和錯誤分類規(guī)則。

但是，異常和錯誤的分類是有跡可循的。比如上面提到的痩客戶端結構，銅錢不足是業(yè)務邏輯范圍內(nèi)的一種失敗情況，它屬于業(yè)務錯誤，再比如程序邏輯上嘗試請求某個URL，最多三次，重試三次的過程中請求失敗是錯誤，重試到第三次，失敗就被提升為異常了。

所以我們可以這樣來歸類異常和錯誤：不會終止程序邏輯運行的歸類為錯誤，會終止程序邏輯運行的歸類為異常。

因為錯誤不會終止邏輯運行，所以錯誤是邏輯的一部分，比如上面提到的瘦客戶端結構，銅錢不足的錯誤就是業(yè)務邏輯處理過程中需要考慮和處理的一個邏輯分支。而異常就是那些不應該出現(xiàn)在業(yè)務邏輯中的東西，比如上面提到的胖客戶端結構，銅錢不足已經(jīng)不是業(yè)務邏輯需要考慮的一部分了，所以它應該是一個異常。

錯誤和異常的分類需要通過一定的思維訓練來強化分類能力，就類似于面向對象的設計方式一樣的，技術實現(xiàn)就擺在那邊，但是要用好需要不斷的思維訓練不斷的歸類和總結，以上提到的歸類方式希望可以作為一個參考，期待大家能發(fā)現(xiàn)更多更有效的歸類方式。

接下來我們講一下速錯和Go語言里面怎么做到速錯。

速錯我最早接觸是在做的時候就體驗到的，當然跟Erlang的速錯不完全一致，那時候也沒有那么高大上的一個名字，但是對待異常的理念是一樣的。

在.NET項目開發(fā)的時候，有經(jīng)驗的程序員都應該知道，不能隨便re-throw，就是catch錯誤再拋出，原因是異常的第一現(xiàn)場會被破壞，堆棧跟蹤信息會丟失，因為外部最后拿到異常的堆棧跟蹤信息，是最后那次throw的異常的堆棧跟蹤信息；其次，不能隨便try catch，隨便catch很容易導出異常暴露不出來，升級為更嚴重的業(yè)務漏洞。

到了Erlang時期，大家學到了速錯概念，簡單來講就是：讓它掛。只有掛了你才會第一時間知道錯誤，但是Erlang的掛，只是Erlang進程的異常退出，不會導致整個Erlang節(jié)點退出，所以它掛的影響層面比較低。

在Go語言項目中，雖然有類似Erlang進程的Goroutine，但是Goroutine如果panic了，并且沒有recover，那么整個Go進程就會異常退出。所以我們在Go語言項目中要應用速錯的設計理念，就要對Goroutine做一定的管理。

在我們的游戲服務端項目中，我把Goroutine按掛掉后的結果分為兩類：1、掛掉后不影響其他業(yè)務或功能的；2、掛掉后業(yè)務就無法正常進行的。

第一類Goroutine典型的有：處理各個玩家請求的Goroutine，因為每個玩家連接各自有一個Goroutine，所以掛掉了只會影響單個玩家，不會影響整體業(yè)務進行。

第二類Goroutine典型的有：數(shù)據(jù)庫同步用的Goroutine，如果它掛了，數(shù)據(jù)就無法同步到數(shù)據(jù)庫，游戲如果繼續(xù)運行下去只會導致數(shù)據(jù)回檔，還不如讓整個游戲都異常退出。

這樣一分類，就可以比較清楚哪些Goroutine該做recover處理，哪些不該做recover處理了。

那么在做recover處理時，要怎樣才能盡量保留第一現(xiàn)場來幫組開發(fā)者排查問題原因呢？我們項目中通常是會在最外層的recover中把錯誤和堆棧跟蹤信息記進日志，同時把關鍵的業(yè)務信息，比如：用戶ID、來源IP、請求數(shù)據(jù)等也一起記錄進去。

為此，我們還特地設計了一個庫，用來格式化輸出堆棧跟蹤信息和對象信息，項目地址：funny/debug · GitHub

通篇寫下來發(fā)現(xiàn)比我預期的長很多，所以這里我做一下歸納總結，幫組大家理解這篇文章所要表達的：

錯誤和異常需要分類和管理，不能一概而論

錯誤和異常的分類可以以是否終止業(yè)務過程作為標準

錯誤是業(yè)務過程的一部分，異常不是

不要隨便捕獲異常，更不要隨便捕獲再重新拋出異常

Go語言項目需要把Goroutine分為兩類，區(qū)別處理異常

在捕獲到異常時，需要盡可能的保留第一現(xiàn)場的關鍵數(shù)據(jù)

以上僅為一家之言，拋磚引玉，希望對大家有所幫助。

Golang 中更好的錯誤處理：理論和實踐技巧

云和安全管理服務專家新鈦云服 張春翻譯

這種方法有幾個缺點。首先，它可以對程序員隱藏錯誤處理路徑，特別是在捕獲異常不是強制性的情況下，例如在 Python 中。即使在具有必須處理的 Java 風格的檢查異常的語言中，如果在與原始調(diào)用不同的級別上處理錯誤，也并不總是很明顯錯誤是從哪里引發(fā)的。

我們都見過長長的代碼塊包裝在一個 try-catch 塊中。在這種情況下，catch 塊實際上充當 goto 語句，這通常被認為是有害的（奇怪的是，C 中的關鍵字被認為可以接受的少數(shù)用例之一是錯誤后清理，因為該語言沒有 Golang- 樣式延遲語句）。

如果你確實從源頭捕獲異常，你會得到一個不太優(yōu)雅的 Go 錯誤模式版本。這可能會解決混淆代碼的問題，但會遇到另一個問題：性能。在諸如 Java 之類的語言中，拋出異常可能比函數(shù)的常規(guī)返回慢數(shù)百倍。

Java 中最大的性能成本是由打印異常的堆棧跟蹤造成的，這是昂貴的，因為運行的程序必須檢查編譯它的源代碼 。僅僅進入一個 try 塊也不是空閑的，因為需要保存 CPU 內(nèi)存寄存器的先前狀態(tài)，因為它們可能需要在拋出異常的情況下恢復。

如果您將異常視為通常不會發(fā)生的異常情況，那么異常的缺點并不重要。這可能是傳統(tǒng)的單體應用程序的情況，其中大部分代碼庫不必進行網(wǎng)絡調(diào)用——一個操作格式良好的數(shù)據(jù)的函數(shù)不太可能遇到錯誤（除了錯誤的情況）。一旦您在代碼中添加 I/O，無錯誤代碼的夢想就會破滅：您可以忽略錯誤，但不能假裝它們不存在！

try {

doSometing()

} catch (IOException e) {

// ignore it

}

與大多數(shù)其他編程語言不同，Golang 接受錯誤是不可避免的。 如果在單體架構時代還不是這樣，那么在今天的模塊化后端服務中，服務通常和外部 API 調(diào)用、數(shù)據(jù)庫讀取和寫入以及與其他服務通信 。

以上所有方法都可能失敗，解析或驗證從它們接收到的數(shù)據(jù)（通常在無模式 JSON 中）也可能失敗。Golang 使可以從這些調(diào)用返回的錯誤顯式化，與普通返回值的等級相同。從函數(shù)調(diào)用返回多個值的能力支持這一點，這在大多數(shù)語言中通常是不可能的。Golang 的錯誤處理系統(tǒng)不僅僅是一種語言怪癖，它是一種將錯誤視為替代返回值的完全不同的方式！

重復 if err != nil

對 Go 錯誤處理的一個常見批評是被迫重復以下代碼塊：

res, err := doSomething()

if err != nil {

// Handle error

}

對于新用戶來說，這可能會覺得沒用而且浪費行數(shù)：在其他語言中需要 3 行的函數(shù)很可能會增長到 12 行 ：

這么多行代碼！這么低效！如果您認為上述內(nèi)容不優(yōu)雅或浪費代碼，您可能忽略了我們檢查代碼中的錯誤的全部原因：我們需要能夠以不同的方式處理它們！對 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)用者返回適當?shù)腻e誤是 API 設計的重要部分，無論是對于內(nèi)部包還是 REST API 。

不必擔心在你的代碼中重復 if err != nil ——這就是 Go 中的代碼應該看起來的樣子。

自定義錯誤類型和錯誤包裝

從導出的方法返回錯誤時，請考慮指定自定義錯誤類型，而不是單獨使用錯誤字符串。字符串在意外代碼中是可以的，但在導出的函數(shù)中，它們成為函數(shù)公共 API 的一部分。更改錯誤字符串將是一項重大更改——如果沒有明確的錯誤類型，需要檢查返回錯誤類型的單元測試將不得不依賴原始字符串值！事實上，基于字符串的錯誤也使得在私有方法中測試不同的錯誤案例變得困難，因此您也應該考慮在包中使用它們。回到錯誤與異常的爭論，返回錯誤也使代碼比拋出異常更容易測試，因為錯誤只是要檢查的返回值。不需要測試框架或在測試中捕獲異常 。

可以在 database/sql 包中找到簡單自定義錯誤類型的一個很好的示例。它定義了一個導出常量列表，表示包可以返回的錯誤類型，最著名的是 sql.ErrNoRows。雖然從 API 設計的角度來看，這種特定的錯誤類型有點問題（您可能會爭辯說 API 應該返回一個空結構而不是錯誤），但任何需要檢查空行的應用程序都可以導入該常量并在代碼中使用它不必擔心錯誤消息本身會改變和破壞代碼。

對于更復雜的錯誤處理，您可以通過實現(xiàn)返回錯誤字符串的 Error() 方法來定義自定義錯誤類型。自定義錯誤可以包括元數(shù)據(jù)，例如錯誤代碼或原始請求參數(shù)。如果您想表示錯誤類別，它們很有用。DigitalOcean 的本教程展示了如何使用自定義錯誤類型來表示可以重試的一類臨時錯誤。

通常，錯誤會通過將低級錯誤與更高級別的解釋包裝起來，從而在程序的調(diào)用堆棧中傳播。例如，數(shù)據(jù)庫錯誤可能會以下列格式記錄在 API 調(diào)用處理程序中：調(diào)用 CreateUser 端點時出錯：查詢數(shù)據(jù)庫時出錯：pq：檢測到死鎖。這很有用，因為它可以幫助我們跟蹤錯誤在系統(tǒng)中傳播的過程，向我們展示根本原因（數(shù)據(jù)庫事務引擎中的死鎖）以及它對更廣泛系統(tǒng)的影響（調(diào)用者無法創(chuàng)建新用戶）。

自 Go 1.13 以來，此模式具有特殊的語言支持，并帶有錯誤包裝。通過在創(chuàng)建字符串錯誤時使用 %w 動詞，可以使用 Unwrap() 方法訪問底層錯誤。除了比較錯誤相等性的函數(shù) errors.Is() 和 errors.As() 外，程序還可以獲取包裝錯誤的原始類型或標識。這在某些情況下可能很有用，盡管我認為在確定如何處理所述錯誤時最好使用頂級錯誤的類型。

Panics

不要 panic()！長時間運行的應用程序應該優(yōu)雅地處理錯誤而不是panic。即使在無法恢復的情況下（例如在啟動時驗證配置），最好記錄一個錯誤并優(yōu)雅地退出。panic比錯誤消息更難診斷，并且可能會跳過被推遲的重要關閉代碼。

Logging

我還想簡要介紹一下日志記錄，因為它是處理錯誤的關鍵部分。通常你能做的最好的事情就是記錄收到的錯誤并繼續(xù)下一個請求。

除非您正在構建簡單的命令行工具或個人項目，否則您的應用程序應該使用結構化的日志庫，該庫可以為日志添加時間戳，并提供對日志級別的控制。最后一部分特別重要，因為它將允許您突出顯示應用程序記錄的所有錯誤和警告。通過幫助將它們與信息級日志分開，這將為您節(jié)省無數(shù)時間。

微服務架構還應該在日志行中包含服務的名稱以及機器實例的名稱。默認情況下記錄這些時，程序代碼不必擔心包含它們。您也可以在日志的結構化部分中記錄其他字段，例如收到的錯誤（如果您不想將其嵌入日志消息本身）或有問題的請求或響應。只需確保您的日志沒有泄露任何敏感數(shù)據(jù)，例如密碼、API 密鑰或用戶的個人數(shù)據(jù)！

對于日志庫，我過去使用過 logrus 和 zerolog，但您也可以選擇其他結構化日志庫。如果您想了解更多信息，互聯(lián)網(wǎng)上有許多關于如何使用這些的指南。如果您將應用程序部署到云中，您可能需要日志庫上的適配器來根據(jù)您的云平臺的日志 API 格式化日志 - 沒有它，云平臺可能無法檢測到日志級別等某些功能。

如果您在應用程序中使用調(diào)試級別日志（默認情況下通常不記錄），請確保您的應用程序可以輕松更改日志級別，而無需更改代碼。更改日志級別還可以暫時使信息級別甚至警告級別的日志靜音，以防它們突然變得過于嘈雜并開始淹沒錯誤。您可以使用在啟動時檢查以設置日志級別的環(huán)境變量來實現(xiàn)這一點。

原文：