不要使用Logrus

這其實和泛型有關。因為Go語言是一門強類型的靜態語言，所以你不可能像NodeJS或者PHP那樣繞過數據類型。那如果我們還需要使用通用的類型怎么辦呢？比如像Loger，或者ORM，因為只有使用了通用的類型，才能編寫出通用的代碼，不然每個都要寫一次。

最終，我們只能用反射。而 Logrus 大量使用反射，這導致大量分配計數。雖然通常不是一個大問題（取決于代碼），但性能很重要，尤其是在大規模、高并發的項目中。雖然這聽起來像是一個非常小的優化，但避免反射很重要。如果你看到一些可以不考慮類型而使用結構的代碼，它會使用反射并且會對性能產生影響。

例如，Logrus 并不關心類型，但顯然 Go 需要知道（最終）。Logrus 怎么辦呢？使用反射來檢測類型，這是開銷。

log.WithFields(log.Fields{<!--{C}%3C!%2D%2D%20%2D%2D%3E-->
“animal”: myWhatever,
}).Info(“A walrus appears”)

所以我會更喜歡zerolog，當然zap也不錯。兩者都宣稱零分配，這也是我們希望的，因為它們的性能影響最小。

不要使用encoding/json

當我們需要一個功能、函數的時候，很多人都建議使用標準庫。但是標準庫中的encoding/json模塊是個例外。其實也和上面的例子一樣，encoding/json使用反射，這會導致性能不高，并且在編寫返回 json 響應的 API 、或者微服務時會造成損失。

比如你可以使用 Easyjson，它很簡單，也很高效，它是使用代碼生成器來創建將結構轉換為 json 所需的代碼，以最大限度地減少分配。這是一個手動構建步驟，很煩人。有趣的是json-iterator也使用反射，但速度明顯更快，我懷疑是黑魔法。

盡可能不要在goroutine中使用閉包

比如，下面這個示例代碼：

for i:=0;i<10;i++ {
  go func() {
     fmt.Println(i)
  }()
}

大多數人可能期望這會打印數字 0 到 9，就像將任務委托給 goroutine 時那樣。

但是實際結果：根據系統，你將得到一兩個數字和許多 10。

為什么會這樣？閉包可以訪問父作用域，因此可以直接使用變量。盡管更新的 linters 可能會警告你“變量閉包捕獲”，但并不會要求你重新聲明該變量。

Go 的性能名聲很大程度上歸功于執行的運行時優化，它嘗試“猜測”你想要做什么并優化某些執行路徑。在此期間，它“捕獲”變量并以理論上最有效的方式將它們傳遞到需要它們的地方（例如，在完成一些非并發操作以釋放某些 CPU 上的分配之后）。這種情況下的結果是循環可能會啟動 goroutines，goroutines可能會在很晚之后從父作用域接收到 i 的值。不能保證在多次執行此代碼時你會看到哪個，可能是數字10，也可以是其他數字。

如果你出于某種原因確實使用了閉包，一定要傳遞變量i，就像對待每個函數一樣對待閉包。

總結