轉(zhuǎn)自：超詳細解讀 Go Modules 應用
在以前，Go 語言的的包依賴管理一直都被大家所詬病，Go官方也在一直在努力為開發(fā)者提供更方便易用的包管理方案，從最初的 GOPATH 到 GO VENDOR，再到最新的 GO Modules，雖然走了不少的彎路，但最終還是拿出了 Go Modules 這樣像樣的解決方案。

目前最主流的包依賴管理方式是使用官方推薦的 Go Modules ，這不前段時間 Go 1.14 版本發(fā)布，官方正式放話，強烈推薦你使用 Go Modules，并且有自信可以用于生產(chǎn)中。

本文會大篇幅的講解 Go Modules 的使用，但是在那之前，我仍然會簡要介紹一下前兩個解決方案 GOPATH 和 go vendor 到底是怎么回事？我認為這是有必要的，因為只有了解它的發(fā)展歷程，才能知道 Go Modules 的到來是有多么的不容易，多么的意義非凡。

1. 最古老的 GOPATH

GOPATH 應該很多人都很眼熟了，之前在配置環(huán)境的時候，都配置過吧？
你可以將其理解為工作目錄，在這個工作目錄下，通常有如下的目錄結構

image.png

每個目錄存放的文件，都不相同

• bin：存放編譯后生成的二進制可執(zhí)行文件
• pkg：存放編譯后生成的 .a 文件
• src：存放項目的源代碼，可以是你自己寫的代碼，也可以是你 go get 下載的包

將你的包或者別人的包全部放在 $GOPATH/src 目錄下進行管理的方式，我們稱之為 GOPATH 模式。

在這個模式下，使用 go install 時，生成的可執(zhí)行文件會放在$GOPATH/bin 下

image.png

image.png

而 GOARCH，表示目標架構，常見的有 arm，amd64 等

這兩個都是 go env 里的變量，你可以通過 go env 變量名 進行查看

image.png

以下幾點是你使用 GOPATH 一定會碰到的問題：

• 你無法在你的項目中，使用指定版本的包，因為不同版本的包的導入方法也都一樣
• 其他人運行你的開發(fā)的程序時，無法保證他下載的包版本是你所期望的版本，當對方使用了其他版本，有可能導致程序無法正常運行
• 在本地，一個包只能保留一個版本，意味著你在本地開發(fā)的所有項目，都得用同一個版本的包，這幾乎是不可能的。

2. go vendor 模式的過渡

為了解決 GOPATH 方案下不同項目下無法使用多個版本庫的問題，Go v1.5 開始支持 vendor 。

以前使用 GOPATH 的時候，所有的項目都共享一個 GOPATH，需要導入依賴的時候，都來這里找，正所謂一山不容二虎，在 GOPATH 模式下只能有一個版本的第三方庫。

解決的思路就是，在每個項目下都創(chuàng)建一個 vendor 目錄，每個項目所需的依賴都只會下載到自己vendor目錄下，項目之間的依賴包互不影響。在編譯時，v1.5 的 Go 在你設置了開啟 GO15VENDOREXPERIMENT=1 （注：這個變量在 v1.6 版本默認為1，但是在 v1.7 后，已去掉該環(huán)境變量，默認開啟 vendor 特性，無需你手動設置）后，會提升 vendor 目錄的依賴包搜索路徑的優(yōu)先級（相較于 GOPATH）。

其搜索包的優(yōu)先級順序，由高到低是這樣的

• 當前包下的 vendor 目錄
• 向上級目錄查找，直到找到 src 下的 vendor 目錄
• 在 GOROOT 目錄下查找
• 在 GOPATH 下面查找依賴包

雖然這個方案解決了一些問題，但是解決得并不完美。

• 如果多個項目用到了同一個包的同一個版本，這個包會存在于該機器上的不同目錄下，不僅對磁盤空間是一種浪費，而且沒法對第三方包進行集中式的管理（分散在各個角落）。
• 并且如果要分享開源你的項目，你需要將你的所有的依賴包悉數(shù)上傳，別人使用的時候，除了你的項目源碼外，還有所有的依賴包全部下載下來，才能保證別人使用的時候，不會因為版本問題導致項目不能如你預期那樣正常運行。

這些看似不是問題的問題，會給我們的開發(fā)使用過程變得非常難受，雖然我是初學者，還未使用過 go vendor，但能有很明顯的預感，這個方案照樣會另我崩潰。

3. go mod 的橫空出世

go modules 在 v1.11 版本正式推出，在最新發(fā)布的 v1.14 版本中，官方正式發(fā)話，稱其已經(jīng)足夠成熟，可以應用于生產(chǎn)上。

從 v1.11 開始，go env 多了個環(huán)境變量： GO111MODULE ，這里的 111，其實就是 v1.11 的象征標志， go 里好像很喜歡這樣的命名方式，比如當初 vendor 出現(xiàn)的時候，也多了個 GO15VENDOREXPERIMENT環(huán)境變量，其中 15，表示的vendor 是在 v1.5 時才誕生的。

GO111MODULE 是一個開關，通過它可以開啟或關閉 go mod 模式。

它有三個可選值：off、on、auto，默認值是auto。

1. GO111MODULE=off禁用模塊支持，編譯時會從GOPATH和vendor文件夾中查找包。
2. GO111MODULE=on啟用模塊支持，編譯時會忽略GOPATH和vendor文件夾，只根據(jù) go.mod下載依賴。
3. GO111MODULE=auto，當項目在$GOPATH/src外且項目根目錄有go.mod文件時，自動開啟模塊支持。

go mod 出現(xiàn)后， GOPATH（肯定沒人使用了） 和 GOVENDOR 將會且正在被逐步淘汰，但是若你的項目仍然要使用那些即將過時的包依賴管理方案，請注意將 GO111MODULE 置為 off。

具體怎么設置呢？可以使用 go env 的命令，如我要開啟 go mod ，就使用這條命令

$ go env -w GO111MODULE="on"

4. go mod 依賴的管理

接下來，來演示一下 go modules 是如何來管理包依賴的。

go mod 不再依靠 $GOPATH，使得它可以脫離 GOPATH 來創(chuàng)建項目，于是我們在家目錄下創(chuàng)建一個 go_test 的目錄，用來創(chuàng)建我的項目，詳細操作如下：

image.png

接下來，進入項目目錄，執(zhí)行如下命令進行 go modules 的初始化

image.png

image.png

上面我們觀察到，在使用 go modules 模式后，項目目錄下會多生成兩個文件也就是 go.mod 和 go.sum 。

這兩個文件是 go modules 的核心所在，這里不得不好好介紹一下。

image.png

go.mod 文件

go.mod 的內(nèi)容比較容易理解

• 第一行：模塊的引用路徑
• 第二行：項目使用的 go 版本
• 第三行：項目所需的直接依賴包及其版本

在實際應用上，你會看見更復雜的 go.mod 文件，比如下面這樣

module github.com/BingmingWong/module-test

go 1.14

require (
    example.com/apple v0.1.2
    example.com/banana v1.2.3
    example.com/banana/v2 v2.3.4
    example.com/pear // indirect
    example.com/strawberry // incompatible
)

exclude example.com/banana v1.2.4
replace（
    Golang.org/x/crypto v0.0.0-20180820150726-614d502a4dac => github.com/golang/crypto v0.0.0-20180820150726-614d502a4dac
    golang.org/x/net v0.0.0-20180821023952-922f4815f713 => github.com/golang/net v0.0.0-20180826012351-8a410e7b638d
    golang.org/x/text v0.3.0 => github.com/golang/text v0.3.0
)

主要是多出了兩個 flag：

• exclude： 忽略指定版本的依賴包
• replace：由于在國內(nèi)訪問golang.org/x的各個包都需要翻墻，你可以在go.mod中使用replace替換成github上對應的庫。

go.sum 文件

反觀 go.sum 文件，就比較復雜了，密密麻麻的。
可以看到，內(nèi)容雖然多，但是也不難理解

每一行都是由 模塊路徑，模塊版本，哈希檢驗值 組成，其中哈希檢驗值是用來保證當前緩存的模塊不會被篡改。hash 是以h1:開頭的字符串，表示生成checksum的算法是第一版的hash算法（sha256）。

值得注意的是，為什么有的包只有一行

<module> <version>/go.mod <hash>

而有的包卻有兩行呢

<module> <version> <hash>
<module> <version>/go.mod <hash>

那些有兩行的包，區(qū)別就在于 hash 值不一行，一個是 h1:hash，一個是 go.mod h1:hash

而 h1:hash 和 go.mod h1:hash兩者，要不就是同時存在，要不就是只存在 go.mod h1:hash。那什么情況下會不存在 h1:hash 呢，就是當 Go 認為肯定用不到某個模塊版本的時候就會省略它的h1 hash，就會出現(xiàn)不存在 h1 hash，只存在 go.mod h1:hash 的情況。[引用自 3]

go.mod 和 go.sum 是 go modules 版本管理的指導性文件，因此 go.mod 和 go.sum 文件都應該提交到你的 Git 倉庫中去，避免其他人使用你寫項目時，重新生成的go.mod 和 go.sum 與你開發(fā)的基準版本的不一致。

5. go mod 命令的使用

• go mod init：初始化go mod， 生成go.mod文件，后可接參數(shù)指定 module 名，上面已經(jīng)演示過。
• go mod download：手動觸發(fā)下載依賴包到本地cache（默認為$GOPATH/pkg/mod目錄）

• go mod graph： 打印項目的模塊依賴結構

  
  
  image.png
• go mod tidy ：添加缺少的包，且刪除無用的包
• go mod verify ：校驗模塊是否被篡改過
• go mod why： 查看為什么需要依賴

• go mod vendor ：導出項目所有依賴到vendor下

  
  
  image.png

• go mod edit ：編輯go.mod文件，接 -fmt 參數(shù)格式化 go.mod 文件，接 -require=golang.org/x/text 添加依賴，接 -droprequire=golang.org/x/text 刪除依賴，詳情可參考 go help mod edit

  
  
  image.png

• go list -m -json all：以 json 的方式打印依賴詳情

  
  
  image.png
  
  

  如何給項目添加依賴（寫進 go.mod）呢？

有兩種方法：

• 你只要在項目中有 import，然后 go build 就會 go module 就會自動下載并添加。

• 自己手工使用 go get 下載安裝后，會自動寫入 go.mod 。

  
  
  image.png

7. 總結寫在最后

如果讓我用一段話來評價 GOPATH 和 go vendor，我會說

GOPATH 做為 Golang 的第一個包管理模式，只能保證你能用，但不保證好用，而 go vendor 解決了 GOPATH 忽視包版的本管理，保證好用，但是還不夠好用，直到 go mod 的推出后，才使 Golang 包的依賴管理有了一個能讓 Gopher 都統(tǒng)一比較滿意的方案，達到了能用且好用的標準。

如果是剛開始學習 Golang ，那么 GOPATH 和 go vendor 可以做適當了解，不必深入研究，除非你要接手的項目由于一些歷史原因仍然在使用 go vender 械管理，除此之外，任何 Gopher 應該從此刻就投入 go modules 的懷抱。

以上是我在這幾天的學習總結，希望對還未入門階段的你，有所幫助。另外，本篇文章如有寫得不對的，請后臺批評指正，以免誤導其他朋友，非常感謝。

8.推薦參考文章

• Go語言之依賴管理
• Go 包依賴管理工具 —— govendor
• Go Modules 終極入門
• 何處安放我們的 Go 代碼
• 零基礎學 Go 語言（27）：超詳細解讀 Go Modules 應用