一、 -mod的设置
在vscode的IDE的settings.json文件可以设置-mod的内容：
具体样例如下：
代码语言：json复制 "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是一个全局的环境变量，也就是在做编译运行时默认的情况
