go mod
Goland
javamavengogo mod

怎么用？

找到你的项目，直接执行

go mod init main.go

go.mod
$ cat go.mod
module collector_go

go 1.14

require (
    github.com/gogo/protobuf v1.3.1 // indirect
    github.com/golang/protobuf v1.4.2
    google.golang.org/protobuf v1.23.0
)

buildrun
go build -o ./collector_go main.go

有一个小前提

golang>=1.12GO111MODULEonauto
go env GO111MODULE=on

他解决了什么问题？

官方golang包管理神器，值得一试！go mod

原来的包管理方式

Go$GOPATH/srcsrc

新的包管理模式解决了以上问题

$GOPATH/srcgo.modreplace

tips

Q1: 我的包下哪去了？

$GOPATH/pkg/mod
GO111MODULEautoonoff
autosrcongo.modoffsrc

Q3: 依赖包中的地址失效了怎么办？比如 golang. org/x/… 下的包都无法下载怎么办？

go.modreplace
replace golang.org/x/text => github.com/golang/text latest

gogithub.com/golang/textgolang.org/x/text
go mod
go.modmodule mainmainimport "项目名/模块名"
Go 1.13

包依赖是怎么查找的？

  • Go 语言在多个工作区中查找依赖包的时候是以怎样的顺序进行的？
  • 如果在多个工作区中都存在导入路径相同的代码包会产生冲突吗？
  • 归档文件是什么
  • 正规的go项目的文件分层和路径是怎么划分的？

Go 语言在多个工作区中查找依赖包的时候是以怎样的顺序进行的？这个问题很重要，不然常常都会找不到包

go分为一般模式和mod模式

对于一般模式，go语言从v1.5开始开始引入vendor模式，首先会在项目根目录下的vendor文件夹中查找，如果没有找到就会去$GOAPTH/src目录下查找。

而vendor的查找顺序是
1. 从引用文件所在的vendor路径下面搜索，
2. 如果没有找到，那么从上层目录的vendor路径下面搜索，
3. 直到src的vendor路径下面搜索。

GO111MODULE=off的时候完整过程是

  1. 优先使用vendor目录下面的包，
  2. 如果vendor下面没有搜索到，再搜索$GOPATH/src下面的包，
  3. 如果GOPATH下面没有搜索到，那么搜索GOROOT/src下面的包，
  4. 要么完整使用vendor下面的包，要么完整使用$GOPATH下面的包，不会混合使用。

在golang>=1.12的版本是默认使用go mod的，是auto的模式，也就是自动查找

  1. 编译时编译器会从工作目录（当前所在目录）开始并逐级向上查找是否具有 go.mod 文件。
  2. 如果有，go.mod 文件中声明的 module 名称就视作 go.mod 所在的路径，然后以指定的 main 包为依赖入口
    3.所有以 go.mod 中声明的 module 名称开头的导入路径都以 go.mod 所在的路径为相对路径进行包的查找导入。
    4.所有需要导入的路径中如果在 go.mod 中指定了版本，则从 GOPATH/pkg/mod/ 下取得相应版本进行导入，如果没有被指定则从GOPATH/src/ 或 $GOROOT/src/ 中进行查找导入。

最后如果没有，就不使用go mod模式，所有依赖均从 GOPATH/src/ 或GOROOT/src/ 中进行查找导入。

如果GO111MODULE=on时，那么就会直接强制使用modules功能

这种模式下，GOPATH不再作为build时导入的角色，依赖包会存放在GOPATH/pkg/mod目录下。工程中的依赖包也会从此目录下查找.

那么又是mod又有vendor呢？

可以用这个项目试验一下

GO111MODULE=on 启用 go module

mod虽好，但是费开发者的电脑磁盘，go mod拉取的软件包都会放在当前目录的pkg/mod目录下面，不像java的maven本地一个集中的目录。其实在go 1.13版本中，go mod下载依赖包目前是放在$GOPATH/pkg/mod目录下，所有项目是共享的。

只有当使用go mod vendor指令后，才会将当前所有依赖包拷贝至当前项目目录下。

有什么好处？下载到vendor目录下，然后直接提交到仓库里，当前项目就可以随意拷贝分发，避免因网络问题造成接收者安装依赖包的麻烦。

所以如果go mod的包版本升级，要手动go mod vendor

go.sum是升级的产物吗?

然后我来到我的项目中，实际上还是使用的$GOPATH/pkg/mod，不会用vendor下的包，我把vendor包删除了，go build还是可以成功，所以对于go mod来说，vendor只是做一个传包的作用，这个是我实验得到的

go.sum 是自动生成的，我们不用管他

它的作用一个是校验，比如tag0.1被删除了，但是重新打一个tag还是0.1，是不一样的

还有就是我在网上查到的，作为 transparent log 来加强安全性，也就是一个历史依赖的日志

https://studygolang.com/articles/25658

参考掘金：https://juejin.im/post/5c9c8c4fe51d450bc9547ba1