[[384341]]

本文轉(zhuǎn)載自微信公眾號(hào)「碼農(nóng)桃花源」，作者曹春暉。轉(zhuǎn)載本文請(qǐng)聯(lián)系碼農(nóng)桃花源公眾號(hào)。    

go mod 是 rsc 主導(dǎo)設(shè)計(jì)的 Go 版本管理工具，借鑒了 Google 內(nèi)部的高大上版本管理方式，摒棄了開(kāi)源社區(qū)的版本管理成功經(jīng)驗(yàn)，借助 MVS 算法，希望能夠走出一條不一樣的路，然而從發(fā)布以來(lái)給廣大 Gopher 帶來(lái)了各種各樣的麻煩。本文簡(jiǎn)單列舉一部分罪狀，Google 的并不一定總是世界的。

當(dāng)然，隨著 Go 1.16 的發(fā)布，其中有些罪證可能已經(jīng)不成立了，讀者可以自行甄別。

Go 命令的副作用

Go list，Go test，Go build，所有命令都會(huì)去拉取依賴(lài)，有些庫(kù)是用被墻的服務(wù)做了重定向，只是執(zhí)行一下 go test，然后就被卡一年是家常便飯。

按照 "By design" 的說(shuō)法，Google 內(nèi)部的依賴(lài)庫(kù)版本都會(huì)盡量使用能夠兼容的最新版本。對(duì)于墻內(nèi)的我們來(lái)說(shuō)，我不管執(zhí)行什么 Go 命令怎么都卡。逐漸患上 go test PTSD。

解法：配置 GOPROXY 代理，雖然拉取依賴(lài)還是慢。

形同虛設(shè)的 semver 規(guī)范

社區(qū)里不遵守 semver 規(guī)范的庫(kù)很多，有的開(kāi)源庫(kù)在 1.7.4 ~ 1.7.5 中進(jìn)行了 breaking change，而按照 semver 的定義，這是不應(yīng)該發(fā)生的。go mod 過(guò)度高估了開(kāi)源社區(qū)的節(jié)操。

一開(kāi)始，我們以為這只是社區(qū)的節(jié)操問(wèn)題，直到我們碰到了 gRPC。

好樣的哦，Google 工程師。

無(wú)法應(yīng)對(duì)刪庫(kù)

leftpad 悲劇重演

js 社區(qū)使用集中式的 npm 來(lái)管理依賴(lài)，在幾年前發(fā)生過(guò)一次因?yàn)樽髡邉h庫(kù)，導(dǎo)致幾乎所有互聯(lián)網(wǎng)巨頭的前端項(xiàng)目全部 build 失敗的悲劇。同時(shí) js 社區(qū)也進(jìn)行了一些反思 how one programmer broke the internet[1]，have we forgotten how to program[2]。

npm 好歹還是集中式的版本管理方式，Go 號(hào)稱(chēng)分布式，但大多 Go 的依賴(lài)庫(kù)都是存在 Github 上，如果 Github 上的原作者刪除了該庫(kù)，那么也會(huì)導(dǎo)致大多數(shù)的依賴(lài)用戶(hù) build 失敗。

即使看起來(lái)我們可以靠 go.mod 和 go.sum 來(lái)實(shí)現(xiàn) reproducible build，實(shí)際的情況是，像 k8s 這樣的項(xiàng)目，依然會(huì)把龐大的依賴(lài)庫(kù)放在自己 repo 的 vendor 里。

在筆者從 dd 離職時(shí)，也曾經(jīng)不小心刪除過(guò)一個(gè)認(rèn)為應(yīng)該沒(méi)有人再依賴(lài)的個(gè)人庫(kù)，當(dāng)時(shí)給前同事們也造成了一些麻煩。

Github release/tag 水土不服

在 Github 上發(fā)布 lib 的 release，或者給某個(gè) commit 打 tag 之后，我們依然可以對(duì)這些 tag 和 release 進(jìn)行編輯：

我們經(jīng)常看到，有些庫(kù)的作者在發(fā)布一個(gè) release 之后，又刪除了這個(gè) release，或?qū)@個(gè) release 進(jìn)行了編輯。對(duì)于用戶(hù)來(lái)說(shuō)，這樣就會(huì)依賴(lài)一個(gè)已經(jīng)“消失”了的版本，在不存儲(chǔ) vendor 的情況下，reproducible build 淪為笑談。

goproxy 的實(shí)現(xiàn)并不統(tǒng)一

不知道是否是因?yàn)?goproxy 并無(wú)規(guī)范，在使用不同的代理幫助我們加速下載依賴(lài)時(shí)，會(huì)出現(xiàn)各種不同的錯(cuò)誤。

例如作者 A 開(kāi)發(fā)的 goproxy，在某個(gè)庫(kù)不存在時(shí)，會(huì)返回 404。而作者 B 開(kāi)發(fā)的 goproxy，在某個(gè)庫(kù)不存在時(shí)，會(huì)返回 500。著實(shí)令人困惑。

而 goproxy 本身的實(shí)現(xiàn)基本都是惰性下載，所以新發(fā)布的庫(kù)，我們要走 goproxy 來(lái)測(cè)試時(shí)，就需要手動(dòng) go get 觸發(fā)。而大多 goproxy 的實(shí)現(xiàn)并沒(méi)有查詢(xún)功能，goproxy 服務(wù)內(nèi)部到底什么時(shí)候同步好了，可以 go get 了，還是 go get 的過(guò)程中發(fā)生失敗了。作為用戶(hù)是不可查的。

go get 到的 lib 版本在 go build 時(shí)被修改

在 go get 時(shí)，可以 go get lib@ver 來(lái)獲取指定版本的依賴(lài)，但是在 go build 時(shí)可能發(fā)現(xiàn)又被修改成了別的版本(比如被升級(jí)了)，非常反直覺(jué)。

我們想要鎖定具體的版本，只能使用 replace。

版本信息擴(kuò)散

由于 go mod 的設(shè)計(jì)，版本信息被包含在了 import 路徑中。當(dāng)依賴(lài)庫(kù)從 v1 升級(jí)至 v2 時(shí)，幾乎一定意味著我們代碼中大量的 import 路徑需要修改。

修改不兼容的 api 就挺累的了。

go.sum 合并沖突

因?yàn)樯厦嬷v到的一系列問(wèn)題，go.sum 在多人維護(hù)的大項(xiàng)目上，經(jīng)常會(huì)發(fā)生變動(dòng)，也就經(jīng)常會(huì)有沖突。對(duì)于中心化版本管理系統(tǒng)來(lái)說(shuō)，這個(gè)問(wèn)題根本就不存在。對(duì)于 go mod 來(lái)說(shuō)，go.sum 合并本來(lái)是個(gè)純追加邏輯。

但這些沖突還是會(huì)浪費(fèi)我們的時(shí)間。

[1]how one programmer broke the internet: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/

[2]have we forgotten how to program: https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/