大家好，我是煎魚。

平時我們經常會進行網上沖浪，學習經驗、知識以及吃瓜。在代碼界，還有同學調侃我們就是 c+v （復制粘貼）工程師。

我的專用快捷鍵：

在 Go 語言中，有一句諺語也指出了 ”復制“ 的有益之處，叫做："A little copying is better than a little dependency"（復制一點總比依賴一點好）。

重點關鍵字是：復制，依賴。

復制一點 vs 引入依賴

復制，只要核心

如果可以自己寫一些短小精悍的代碼，那就沒有必要直接導入一個庫去做（可以只復制核心算法）。

例如 UUID 的案例：

func main() {
 f, _ := os.Open("/dev/urandom")
 b := make([]byte, 16)
 f.Read(b)
 f.Close()
 uuid := fmt.Sprintf("%x-%x-%x-%x-%x", b[0:4], b[4:6], b[6:8], b[8:10], b[10:])
 fmt.Println(uuid)
}

雖然有很多 UUID 的第三方庫，但普遍會有許多功能堆積在一個庫中，這樣會引入許多不必要的新依賴。

如果只是要一點新功能，可以自己簡單實現，封裝為公司內部方法導入。

可以有效減少依賴管理的負擔，縮小二進制文件大小，帶來更大的穩定性、安全、測試第三方庫這方面大多都是不清楚的。

引入大依賴，易折騰

指向的副作用是在我們引用依賴了太多的東西時，會導致產生一個應用，依賴過多的場景：

比較經典的是微服務的依賴。更貼近我們的場景，那就是 Go modules 中帶來的各第三方組件庫的版本互相制衡了。

最小版本選擇

以下介紹的是 Go Modules 的最小版本選擇的計算規則，其會帶來版本間的互相制衡。

一個模塊往往依賴著許多其它許許多多的模塊，并且不同的模塊在依賴時很有可能會出現依賴同一個模塊的不同版本，如下圖（來自Russ Cox）：

在上述依賴中，模塊 A 依賴了模塊 B 和模塊 C，而模塊 B 依賴了模塊 D，模塊 C 依賴了模塊 D 和 F，模塊 D 又依賴了模塊 E，而且同模塊的不同版本還依賴了對應模塊的不同版本。那么這個時候 Go modules 怎么選擇版本，選擇的是哪一個版本呢？

我們根據 proposal 可得知，Go modules 會把每個模塊的依賴版本清單都整理出來，最終得到一個構建清單，如下圖（來自Russ Cox）：

我們看到 rough list 和 final list，兩者的區別在于重復引用的模塊 D（v1.3、v1.4），其最終清單選用了模塊 D 的 v1.4 版本。

真實場景

在 Go RPC 的使用中，gRPC 的應用是非常廣泛的。而 gRPC、grpc-gateway、protoc（含對應語言的 plugin）、etcd，幾者的版本是會有不兼容的情況的。

例如：gRPC 本身會做一些實驗性的 package，etcd 在 v3.5.0 前沒有 Go modules 的良好版本管理，同時 protoc 的高版本又會對 gRPC 的版本有一定的要求，會形成各第三方庫對各庫版本有要求的情況。

在內部框架或應用中，我們常常會通過 go.mod 來聲明所使用的版本。但在 ”最小版本選擇“ 的存在下，其遵守版本化，一旦依賴的另外一個庫，要求更高的 gRPC 版本，就會打破這個平衡。

最近一次見到的，就是公司內有人使用 TIDB 的庫，只是使用了某一塊東西，但卻導致大量被依賴的版本被動升級。

最終這位同學就采取了復制一點的做法，解決了增加大量依賴的副作用。

總結

實際上 Go 的這句諺語 "A little copying is better than a little dependency"，更多的是一種軟件工程里的指導思想。

當你只是涉及到一個很簡單的功能，那完全可以自行實現或復制核心代碼。沒必要直接導入一個大的第三方庫，它有可能帶來許多奇奇怪怪的依賴，使得你的編譯構建變得緩慢，依賴管理也復雜了起來。

這是需要我們都好好思考的。