為什么 Go 用起來會難受？這六個坑你知道嗎
在做新的應用選型時，我們會進行應用編程語言的選擇，這時會糾結 Java、PHP、Go...各種，會思考有沒有致命的問題，不能用?
可以明確的是，Go 沒有非常致命的問題，否則你我他都不會在這里相遇，也不會大火。
難受的點，倒是有不少，今天就由煎魚和大家一起來看看。
難受的點
泛型
在 Go1.18 以前，在所有社交媒體和調查報告上來看。Go 最難受的莫過于沒有泛型，
寫一個通用的方法，要不得把入參聲明為 interface，要不得寫 N 個不同類型的一樣代碼的函數，代碼重復率高。
如下圖：
這是 Go1.18 以前最難受的點，現在新版本雖然有了泛型，但現階段配套標準和開源庫還沒完全到位，影響還是會繼續存在。
淺拷貝和泄露
在寫 Go 程序時，我們經常要用到 slice、map 等基礎類型。但有一個比較麻煩的點，就是會涉及到淺拷貝。
一個不注意就會引起 BUG，如下代碼：
type T struct {
A string
B []string
}
func main() {
x := T{"煎魚", []string{"上班"}}
y := x
y.A = "咸魚"
y.B[0] = "下班"
fmt.Println(x)
fmt.Println(y)
}
輸出結果是什么?
煎魚到底是上班了，還是下班了?
結果如下：
{煎魚 [下班]}
{咸魚 [下班]}
實際上在 y := x 時，他拷貝的是指向對象的指針，這個時候 x 和 y 的底層數據其實是一家子，自然一變動 y，x 的煎魚也就下班了。
同類型的 slice 也有 append 的泄露，以及 len、cap 的不準確問題，是比較折騰人的。
泄露的示例：
var a []int
func f(b []int) []int {
a = b[:2]
return a
}
func main() {
...
}
有興趣的可以具體看《Go 切片導致內存泄露，被坑兩次了!》的解析。
錯誤處理
在 Go 的錯誤處理中，許多小伙伴的難受的點分兩大塊。一個是大量重復的 if err != nil 的代碼：
func main() {
x, err := foo()
if err != nil {
// handle error
}
y, err := foo()
if err != nil {
// handle error
}
z, err := foo()
if err != nil {
// handle error
}
s, err := foo()
if err != nil {
// handle error
}
}
另外一塊是在異常處理中，Go 現階段是 panic 和 recover 的模式，內部還包含 throw 的致命性錯誤拋出，無法攔截，為此我也見過個別事故是因此造成的。
這是一個爭議性很大的板塊。
nil 接口不是 nil
我們強行將一段 Go 程序的變量值賦為 nil，并進行 nil 與 nil 的判斷。
代碼如下：
func main() {
var v interface{}
v = (*int)(nil)
fmt.Println(v == nil)
}
輸出的結果是什么。是 false，還是 true，又或是拋出異常?
輸出結果是 fasle，nil 可不 100% 等于 nil。
這與 interface 的內部數據結構有關，是在編程時要注意的一個細節，具體可詳見《Go 面試題：Go interface 的一個 “坑” 及原理分析》的解析。
垃圾回收
Go 非常簡潔，垃圾回收唯一的可調節的是 GC 頻率，可以通過 GOGC 變量設置初始垃圾收集器的目標百分比值。
$ GOGC=100 eddycjy
簡單來講就是，GOGC 的值設置的越大，GC 的頻率越低，但每次最終所觸發到 GC 的堆內存也會更大。
然后就沒別的方式可以優化垃圾回收器本身了，以至于當年我還被人拿 Java 來吐槽過一遍，說 Go 肯定有。
依賴管理
壓軸的難受點，莫過于 Go 的依賴管理。先是從 GOPATH 時代，開源后一路水土不服，后面 rsc 直接下場支棱起來硬推。
到 2022 年，目前 Go modules 還是會存在一些讓人難受的點。甚至曹大總結了 《Go mod 七宗罪》，不少我在工作中也遇到和替別人解決過，非常的精辟。
引用曹大文章中的 7 點：
- Go 命令的副作用：所有 go build、go list、go test 多多少少都會拉取到墻外的資源，會很慢。
- 形同虛設的 semver 規范：go mod 的設計，就是希望大家在軟件庫發布時都要遵守標準，例如在小版本時，要保持兼容性。但這非常理想化，現實就是經常有人不遵守。
- 無法應對刪庫：發布后的軟件庫，你已經拉取了。但發布者依然可以刪除，受傷的還是自己。
- goproxy 的實現并不統一：作者 A、作者 B、作者 C 寫的幾套 goproxy 內部邏輯是不完全一致的，很折騰人。
- go get 到的 lib 版本在 go build 時被修改。
- 版本信息擴散：導入路徑是包含版本號 v1、v2 等信息的，一旦修改，就得大面積替換。
- go.sum 合并沖突：大型項目上的多人維護，導致頻繁沖突。
熟悉掌握 Go 的一個表現，那就是精通 Go modules，不然項目都運行的不順利。
總結
今天我們圍繞 Go 的難受場景進行了分析和講解，本文涉及的分別是：泛型、淺拷貝和泄露、錯誤處理、nil 接口不是 nil、垃圾回收、依賴管理。
其中不少是常見的，也有的是有意而為之(例如：垃圾回收)。從大家的角度來看，你覺得 Go 比較難受的點還有哪些呢?
