因爲之前一直是 C++ Coder，根本沒有所謂的包管理，項目依賴一塌糊塗，說到 C++ 的不便之處還得吐槽一句，編譯速度賊慢，每次項目中寫完代碼等待編譯的時候就想着，以後再也不想用 C++ 寫代碼了。
說回正題，go mod 包管理工具
沒有包管理之前，項目管理會出現什麼問題
在沒有包管理方案之前，項目依賴於 GOPATH，這樣帶來一些不便之處：
多項目難以管理。試想一下，A 項目和 B 項目 同時依賴於一個 C 項目，但是依賴於 C 項目的不同版本，如何解決，只能通過多 GOPATH 設置。
項目的依賴只能夠手動 go get 下載到 GOPATH 中，如果換一臺服務器開發項目，光是包依賴都得弄半天。
go mod 出來之前，其他方案的是怎麼設計的？
godep，glide，go verdor 這些都是曾經出現過的包管理解決方案。
挑 go vendor 說一下，他是如何解決上面的兩個問題的。
對於多項目，他是在項目中創建一個文件夾 vendor，將項目的依賴都放在裏面，這樣就實現了多項目分開管理依賴。
對於手動下載包，他會將項目依賴的信息和版本統一記錄在一個文件中，這樣遷移環境只需要執行特定命令就能將依賴包都下載到 vendor 文件夾中
在 go mod 出來之前，go vendor 包管理模式是受很多大牛推崇的，也是非常好的方案。
當然也有一點小瑕疵：
- 多個項目都依賴於同版本的 A 項目，則 A 項目需要冗餘存儲多份。
go mod 是怎麼設計的？
既然 go vendor 已經成熟了，爲什麼不直接扶正呢，因爲 google 爸爸有自己的想法。
這就是我們今天的重點 go mod 包管理方案。
go mod 和 go vendor 類似，有統一的目錄管理包依賴，但是是統一放在 $GOPATH/pkg/mod 裏面，對於多版本管理見下圖。
和 go vendor 一樣，項目中有文件記錄項目的包依賴和版本號，go.mod 和 go.sum
go mod 使用篇
常用命令：
go mod graph 把模塊之間的依賴圖顯示出來
go mod init 初始化模塊（例如把原本dep管理的依賴關係轉換過來）
go mod tidy 增加缺失的包，移除沒用的包
go mod vendor 把依賴拷貝到 vendor/ 目錄下
go mod verify 確認依賴關係
go mod why 解釋爲什麼需要包和模塊
go mod 啓用的三種模式
- on：開啓 Go mod 模式
- off：關閉 Go mod 模式
- auto (默認模式)：如果代碼在gopath下，則自動使用gopath模式；如果代碼不在gopath下，則自動使用GO mod模式。
大陸額外福利
經常會有一些包，比如 golang.org/x/net 等，無法直接下載。
只需要添加環境變量即可
export GOPROXY=https://goproxy.io
一起愉快的用 go mod 吧
使用例子：
初識RPC
示例代碼地址 go-micro-demo