GO -mod和​GO111MODULE设置的那些事

一、 -mod的设置

在vscode的IDE的settings.json文件可以设置-mod的内容：

具体样例如下：

 "go.toolsEnvVars": {         
      "GOFLAGS": "-mod=mod"    
       },

上面设置意味着在VSCode的IDE中，不论是代码跳转还是编译运行都生效-mod=mod的设置

其中，-mod有几个枚举方式：

1.-mod=mod：

意味着，忽略vendor文件夹，且对代码引用的（import）库列表自动更新到go.mod文件中，适用于带网络的研发环境调试编译

如果需要go.mod对应的库内容，经过go mod tidy命令后，引用的内容（即go.mod）会下载到module cache目录下（默认值是GOPATH/pkg/mod，在1.15版本后，可以通过设置GOMODCACHE来改变），同时也会删除多余的引用的内容， 确保 go.mod 文件与模块中的源代码匹配。

在gopls（VSCode的IDE的用于代码解析和调转插件）的作用下，点击引用的方法，可以直接跳转到gopath文件夹下的源码

使用go get 安装新的包只能在-mod=mod的情况下

2.-mod=vendor：

意味着，直接引用（import）当前目录下vendor文件夹的内容，而不用module cache目录下（默认值是GOPATH/pkg/mod，在1.15版本后，可以通过设置GOMODCACHE来改变）的内容，可以理解为完全的本地编译，无需网络依赖，适用于真实项目的编译使用

如果需要更新vendor的库内容，有两种方式，一种直接手动更新vendor的内容，另一种是go mod vendor更新内容，需要注意的是，第二种会将当前目录下vendor目录直接删除，重新下载，所以如果要修改内容，就不用go mod vendor命令

在gopls（VSCode的IDE的用于代码解析和调转插件）的作用下，点击引用的方法，可以直接跳转到vendor文件夹下的源码

不能使用go get命令

3.-mod=readonly：

意味着，忽略vendor文件夹，提示代码引用的（import）库列表与go.mod文件中的内容不符，与-mod=mod的区别是不更新go.mod的内容，其他的与-mod=mod一致

4.默认使用：

如果在go.mod设置了go版本，且go版本大于1.14（含），且vendor文件存在，则相当于设置成了-mod=vendor，否则则设置成了-mod=readonly

参考来源：https://go.dev/ref/mod

二、GO111MODULE的设置

Go Modules 演进史

GOPATH。当 Go 在 2009 年首次推出时，它并没有随包管理器一起提供。取而代之的是 go get，通过使用它们的导入路径来获取所有源并将其存储在 $ GOPATH / src 中。没有版本控制并且『master』分支表示该软件包的稳定版本。

Go 1.11 引入了 Go 模块 (以前称为 vgo- 版本为 Go)。 Go Modules 不使用 GOPATH 存储每个软件包的单个 git checkout，而是存储带有 go.mod 标记版本的标记版本，并跟踪每个软件包的版本。

从那时起，『GOPATH 行为』与『Go Modules 行为』之间的交互已成为 Go 的最大难题之一。一个环境变量造成了 95％的痛苦：GO111MODULE。

Go v1.11 v1.12

从 Go v1.11 开始支持 Go Moduls。

为了兼容使用 Go v1.11 之前的任意版本的项目，当设置 GO111MODULE=auto 或 GO111MODULE=off 时，Go v1.11 在 $GOPATH/src 中，继续使用 GOPATH 模式。

当设置 GO111MODULE=auto 时，其它任意位置，如果当前目录或父目录包含 go.mod 文件，则使用 Modules 模式。

注意：GO111MODULE 包含三个模式，分别是 auto、on 和 off，其中默认值是 auto，即不显式设置 GO111MODULE 的值，默认是 auto 模式。

Go v1.13

在 Go v1.13 中，Go Modules 发生一些变化：

当设置 GO111MODULE=auto 时，如果在任意位置找到 go.mod 文件，则使用 Go Modules 模式，即使在 $GOPATH/src 中。

注意：在 Go v1.13 之前，即使 GO111MODULE=auto，在 $GOPATH/src 目录中也不会启动 Go Modules 模式。

go get 的变化：

go get -u （不包含任何参数），现在只升级当前包的直接和间接依赖，并且不再检查整个模块。

go get -u ./... 从模块根升级模块的所有直接和间接依赖项，现在排除测试依赖项。

go get -u -t ./... 从模块根升级模块的所有直接和间接依赖项，而且还会升级测试依赖项。

Go v1.14

从 Go v1.14 开始，模块被认为可以用于生产环境，并且鼓励所有用户从其他依赖管理系统迁移到模块。

当主模块包含一个顶级 vendor 目录，并且它的 go.mod 文件指定 go 1.14 或更高版本时，对于支持 -mod=vendor 的 go 命令，将默认添加 -mod=vendor。

Go v1.15

模块缓存的位置现在可以使用 GOMODCACHE 环境变量进行设置。GOMODCACHE 的默认值是 GOPATH0/pkg/mod，这也是不支持使用 GOMODCACHE 环境变量进行设置之前的模块缓存的位置。

注意：可以使用 GOPATH 环境变量设置多个目录。

Go v1.16

模块模式（GO111MODULE=on）默认开启，也就是说默认启用 Go Modules 模式，如果用户想要使用 GOPATH 模式，需要显式设置 GO111MODULE=off 或 GO111MODULE=auto（并且需要在 $GOPATH/src 目录）。

使用 go install pkg@version 替换 go get pkg@version 全局安装包和可执行文件。

注意：在 Modules 模式 go get 不再用于构建或安装包，而是专门用于调整 go.mod 中的依赖项，如果在模块外执行 go get 将会报错，因为没有可更新的 go.mod 文件；在 GOPATH 模式（GO111MODULE=off） go get 仍然构建和安装包。

参考来源：https://cloud.tencent.com/developer/article/2238787

三、两者的关系是什么样的？

-mod是执行go命令的一个参数，从官方的文档中看到：

-mod主要作用以下一些命令

而GO111MODULE是一个全局的环境变量，也就是在做编译运行时默认的情况