golang 官方並沒有推薦最佳的包管理方案。到了1.5版本時代，官方引入包管理的設計，加了 vendor 目錄來支援本地包管理依賴。官方 wiki 推薦了多種支援這種特性的包管理工具，如：godep、gv、gvt、glide、govendor等。
下面簡要介紹乙個我在專案中用到的 –govendor。
該工具將專案依賴的外部包拷貝到專案下的 vendor 目錄下，並通過 vendor.json 檔案來記錄依賴包的版本，方便使用者使用相對穩定的依賴。
對於 govendor 來說，依賴包主要有以下多種型別:
狀態縮寫狀態
含義+local
l本地包，即專案自身的包組織
+external
e外部包，即被 $gopath 管理，但不在 vendor 目錄下
+vendor
v已被 govendor 管理，即在 vendor 目錄下
+std
s標準庫中的包
+unused
u未使用的包，即包在 vendor 目錄下，但專案並沒有用到
+missing
m**引用了依賴包，但該包並沒有找到
+program
p主程式包，意味著可以編譯為執行檔案
+outside
外部包和缺失的包
+all
所有的包
go get -u github.com/kardianos/govendorgovendor，若出現以下資訊，則說明安裝成功。
govendor (v1.0
.8): record dependencies and
copy
into vendor folder
-govendor-licenses show govendor's licenses.
-version show govendor version
......
warning：需要把$gopath/bin/加到path中。
# setup your project.
cd "my project in gopath"
# 初始化 vendor 目錄, project 下出現 vendor 目錄
govendor init
# add existing gopath files to vendor.
govendor add +external
# view your work.
govendor list
# look at what is using a package
govendor list -v fmt
# specify a specific version or revision to fetch
govendor fetch golang.org/x/net/context@a4bbce9fcae005b22ae5443f6af064d80a6f5a55
# get latest v1.*.* tag or branch.
govendor fetch golang.org/x/net/context@v1
# get the tag or branch named "v1".
govendor fetch golang.org/x/net/context@=v1
# update a package to latest, given any prior version constraint
govendor fetch golang.org/x/net/context
# format your repository only
govendor fmt +local
# build everything in your repository only
govendor install +local
# test your repository only
govendor test +local
init 建立 vendor 資料夾和 vendor.json 檔案
list 列出已經存在的依賴包
add 從 $gopath 中新增依賴包，會加到 vendor.json
update 從 $gopath 公升級依賴包
remove 從 vendor 資料夾刪除依賴
status 列出本地丟失的、過期的和修改的package
fetch 從遠端庫增加新的，或者更新 vendor 檔案中的依賴包
sync pull packages into vendor folder
from remote repository with revisions
migrate move packages from
a legacy tool to
the vendor folder
with metadata.
get 類似 go get，但是會把依賴包拷貝到 vendor 目錄
license list discovered licenses for
the given status or import paths.
shell run a
"shell"
to make multiple sub-commands more efficient for large projects.
`+` package selection may be used with them
fmt, build, install, clean, test, vet, generate, tool
隨著go 1.5 release版本的發布，vendor目錄被新增到除了gopath和goroot之外的依賴目錄查詢的解決方案。在go 1.6之前，你需要手動的設定環境變數go15vendorexperiment=1才可以使go找到vendor目錄，然而在go 1.6之後，這個功能已經不需要配置環境變數就可以實現了。
note，即使使用vendor，也必須在gopath中，在go的工具鏈中，你逃不掉gopath的那麼查詢依賴包路徑的解決方案如下：
在使用vendor中，給出如下建議：
乙個庫工程（不包含main的package）不應該在自己的版本控制中儲存外部的包在vendor目錄中，除非他們有特殊原因並且知道為什麼要這麼做。
在乙個應用中，（包含main的package），建議只有乙個vendor目錄在**庫一級目錄。
上面建議的原因如下：
工程目錄如下：
-vendor/a/在這個例子中，兩個apackage都是完全一樣的，b package在**庫中儲存了a package，在頂級應用**中也引用了a包。
檔案foo.go做了很簡單的事情：
func main().ain argument to b.do你可以clone這個測試工程到本地重現。
如果我們已經使用gopath去儲存packages了，問什麼還需要使用vendor目錄呢？這是乙個很實戰的問題。
假如多個應用使用乙個依賴包的不同版本？這個問題不只是go應用，其他語言也會有這個問題。
vendor目錄允許不同的**庫擁有它自己的依賴包，並且不同於其他**庫的版本，這就很好的做到了工程的隔離。
glide
我們發現glide是非常好的包管理解決方案，他將依賴包平展開存放在頂級vendor目錄中，如果乙個包被另乙個程式引用了，那麼這個包最好不要儲存外部依賴項。如果使用glide，你可以在glide.yml檔案中指定依賴包，glide會幫你管理，並使用正確的版本。
golang 依賴管理之 mod
go 很早就考慮了依賴管理的問題，內建go get命令，可以直接獲取對應的依賴，非常方便，但是有乙個巨大的缺陷，沒有版本的維護和管理，而版本不一致可能會導致各種相容性問題，因此出現了很多第三方依賴管理工具，dep和glide就是其中的佼佼者，到了 go 1.11 官方終於推出了自己的依賴管理工具mo...
go module管理依賴包
go mod 最大的好處就是擺脫了gopath這個限制，在除了gopath以外的目錄下也能開展你的專案 go mod使用 1，確保你的go版本是1.1以上 2，建立乙個專案目錄example，並新增乙個go檔案 3，開啟命令列，切換到該目錄。4，設定環境變數，set go111module on 表...
Golang 依賴管理工具
使用 vendor 目錄 go module proxy go vendor depgo mod 使用 再探go modules 使用與細節 go的包管理工具 三 go modules go的包管理工具 四 go module proxy go 模組解惑 到處都是 go111module 這到底什麼...