Go module遵循語義化版本規范 2.0.0 major.minor.patch
樣板分析
1. model path
一行是module path, 一般采用倉庫地址方式定義。這樣我們獲取一個module的時候，就可以到它的倉庫中去查詢，或者讓go proxy到倉庫中去查詢。
如果版本大於2.0.0，按照規范，需要加上major后綴，比如加上v2,v3，以便和其它major版本進行區分。
// 不同tag, module名不一樣 module githup.com/panicthis/modfile/v2
這樣 go mod 通過不同的major版本，讓他們共存，也就是識別成獨立的包
2.go directive
第二行是go directive,不是指你當前使用的Go版本，而是指名你的代碼所需要的Go的最低版本
go 1.16
3.require
require段中列出了項目所需要的各個依賴庫以及它們的版本，除了正規的v1.3.0這樣的版本外
4.incompatible
這些庫采用了go.mod的管理，但是不幸的是，雖然這些庫的版major版本已經大於等於2了，但是他們的module path中依然沒有添加v2、v3這樣的后綴。
標記為不規范，這樣不同major版本，共存也就失效了， go mod 會選擇最新版本，因為默認是新版本是兼容舊版本的。
5.包依賴沖突的問題
- major 特性：包同時共存。在Go中，由於采用語義導入版本機制，major版本號不同的module被視為不同的module，即使它們源於同一個repository(比如上面的源於同一個P3的v1.5和v2.0就被視為兩個不同的module)。
當然這種解決方案是有代價的！第一個代價就是構建出來的app的二進制文件size變大了，因為二進制文件中包含了多個版本的P3的代碼；第二個代價，可能也算不上代價，更多是要注意的是不同版本的module之間的類型、變量、標識符不能混用，我們以go-redis/redis這個開源項目舉個例子。go-redis/redis最新大版本為v8.11.4，沒有啟用go.mod時的版本為v6.x.x，我們將這兩個版本混用在一起。
2）歷史遺留問題，有些項目沒有使用go mod 模式，所以項目中go.mod文件，
那么不同major的包共存特性也就沒有，如果同時引用的話，那么會選擇最新的版本。