go1.11的module機制和dep/govendor機制問題

module機制和dep/govendor機制是否衝突？

自從go團隊推出module機制後，go團隊和dep社區發生了一些衝突，有一篇有名的爭論《關於Go Module的爭吵》，讀後給人一種錯覺，似乎module機制和dep/govendor機制是不相容的。但是仔細分析二者的運行機制，其實兩者並無衝突，反而是互補性質的。

module機制由環境變數GO111MODULE控制，它有三個值：off、on、auto，預設值是auto。在auto模式下，在$GOPATH/src路徑下build時，預設使用vendor、GOPATH匯入第三方包，而在GOPATH之外編譯時間，預設使用go.mod設定匯入項目。我們知道vendor機制只有在GOPATH路徑之下才起作用，到了GOPATH之外就沒用了。所以module機制可以看作是vendor機制的一個補充，在GOPATH之內，它可以和dep/govendor一樣把依賴包匯入vendor目錄，同時它又提升了go語言的靈活性，我們的原始碼不再必須儲存到GOPATH中，可以靈活組織目錄結構。

什麼情況下使用module機制？

• 當你依賴的所有第三方包都通過git伺服器託管的時候，非常適合使用module機制。

• 當你大量使用本地第三方包的時候，不太適合使用module機制。

因為module模式使用本地第三方包必須編輯go.mod，用replace命令指向當地套件目錄。

因為網路原因，在我們國內使用module機制有時候並不太方便，當我們要使用來自golang.org這類被屏蔽的網站的包時，我們一般必須通過其他方式下載到本地，然後編輯go.mod用replace命令指向本地目錄，這樣還不如就用vendor方式方便，除非你有特殊原因，必須在GOPATH之外儲存原始碼。在上面這種情況下，我推薦把下載的第三方包存放在vendor目錄中，這樣就可以相容非module模式。

當使用本地的私人第三方包時，還是vendor模式比較方便，因為module模式使用本地第三方包必須編輯go.mod，用replace命令使用當地套件。

初窺Go module
關於Go Module的爭吵

end