相信看我文章的文章的童鞋,golang版本已經是1.3版本以上。如果你的版本還停留在1.3以下,那這篇文章可以做為你的提升之法。
go moudle的前世今生
前世-gopath
gopath是什麼
GOPATH 是什麼,相信已經不用我再多說什麼了。大家深受摧殘多年,應該已經有所體會。在v.1.11版本之前,安裝GO肯定要在環境變數中配置GoPath
,我們可以簡單的將其理解成是工作目錄。目錄結構如下
-- bin 存放編譯後生成的二進位制可執行檔案
-- pkg 存放編譯後生成的 .a
檔案
-- src 存放專案的原始碼,可以是你自己寫的程式碼,也可以是你 go get 下載的包
將你的包或者別人的包全部放在 $GOPATH/src
目錄下進行管理的方式,我們稱之為 GOPATH 模式。
gopath有什麼樣的問題?
版本管理問題
GOPATH 根本沒有版本的概念,如果你所應用的庫需要升級,那就是全域性升級,所以涉及這個庫的服務在下一次編譯中都會使用新的庫,這是一件很危險的事情。版本管理非常重要,自己應該管理好自己的引用庫。
協同開發問題
當其他的開發者get到原始碼進行修改的時候,你無法保證他下載的包是不是你所期望的版本,這及有可能導致服務出錯,且很難查詢原因。
今生-GoMoudle
go modules 在 v1.11 版本正式推出,在釋出的 v1.14 版本中,官方正式發話,稱其已經足夠成熟,可以應用於生產上。
從 v1.11 開始,go env
多了個環境變數: GO111MODULE
,這裡的 111,其實就是 v1.11 的象徵標誌, go 裡好像很喜歡這樣的命名方式,比如當初 vendor 出現的時候,也多了個 GO15VENDOREXPERIMENT
環境變數,其中 15,表示的vendor 是在 v1.5 時才誕生的。
GO111MODULE
是一個開關,通過它可以開啟或關閉 go mod 模式。
它有三個可選值:off
、on
、auto
,預設值是auto
。
GO111MODULE=off
禁用模組支援,編譯時會從GOPATH
和vendor
資料夾中查詢包。GO111MODULE=on
啟用模組支援,編譯時會忽略GOPATH
和vendor
資料夾,只根據go.mod
下載依賴。GO111MODULE=auto
,當專案在$GOPATH/src
外且專案根目錄有go.mod
檔案時,自動開啟模組支援。
go mod 出現後, GOPATH(肯定沒人使用了) 和 GOVENDOR 將會且正在被逐步淘汰,但是若你的專案仍然要使用那些即將過時的包依賴管理方案,請注意將 GO111MODULE 置為 off。
具體怎麼設定呢?可以使用 go env 的命令,如我要開啟 go mod ,就使用這條命令
go env -w GO111MODULE="on"
go mod 使用
go mod 不再依靠 $GOPATH,使得它可以脫離 GOPATH 來建立專案
你可以在你電腦的任意位置建立一個資料夾go_demo
使用 go mod 命令初始化,此時目錄下只有2個檔案,go.mod是執行命令後生成的檔案。
go mod init go_demo
檔案main.go
解釋:引入一個now的時間處理庫,輸出時間
package main
import (
"fmt"
"github.com/jinzhu/now"
)
func main() {
fmt.Println("hello world", now.BeginningOfDay())
}
go.mod內容
module go_demo
go 1.15
require github.com/jinzhu/now v1.1.1
內容解釋:
- 第一行:模組的引用路徑
- 第二行:專案使用的 go 版本
- 第三行:專案所需的直接依賴包及其版本
此時我們在命令列執行go build
進行編譯,發現多了一個go.sum檔案,那麼這個檔案又是什麼?
go.sum 檔案相比go.mod就比較複雜了。雖然內容多,但是也不難理解。
每一行都是由 模組路徑
,模組版本
,雜湊檢驗值
組成,其中雜湊檢驗值是用來保證當前快取的模組不會被篡改。hash 是以h1:
開頭的字串,表示生成checksum的演算法是第一版的hash演算法(sha256)。
go.mod 和 go.sum 是 go modules 版本管理的指導性檔案,因此 go.mod 和 go.sum 檔案都應該提交到你的 Git 倉庫中去,避免其他人使用你寫專案時,重新生成的go.mod 和 go.sum 與你開發的基準版本的不一致。
go mod的好處
相比gopath
的方式,go mod
的好處顯而易見。你不必為了版本依賴費勁頭腦,模組化自動幫你做好了。這就有點C#中Nuget的味道,node的npm的感覺。開發者不應為了這種事情操心,而應該專注於編碼問題。
go mod 命令使用
常用
go mod init
:初始化go mod, 生成go.mod檔案,後可接引數指定 module 名,上面已經演示過。
go mod download
:手動觸發下載依賴包到本地cache(預設為$GOPATH/pkg/mod
目錄)
go list -m -json all
:以 json 的方式列印依賴詳情
不常用
go mod graph
: 列印專案的模組依賴結構go mod tidy
:新增缺少的包,且刪除無用的包go mod verify
:校驗模組是否被篡改過go mod why
: 檢視為什麼需要依賴go mod vendor
:匯出專案所有依賴到vendor下go mod edit
:編輯go.mod檔案
如何看待go moudle並應用於工作
go mode 方式肯定是推薦的一種方式,如果不是基於歷史專案-使用GOPATH,推薦儘快使用go mod方式,這能讓你省去很多糟心的事情。但是如果公司的專案還有不少就是基於gopath方式的,那你也不要著急,gopath的舊專案也是支援切換成go mod模式的,方式也很簡單,大家動動小手,一百度就可以。當然正式的切換肯定是需要領導同意的,畢竟工作系統隨意切換還是有風險的。
參考文章
關於我
最後
本文到此結束,希望對你有幫助 ?
如果還有什麼疑問或者建議,可以多多交流,原創文章,文筆有限,才疏學淺,文中若有不正之處,萬望告知。
更多精彩技術文章彙總在我的 公眾號【程式設計師工具集]】,持續更新,歡迎關注訂閱收藏。