gomod 的作用
失常状况下，当咱们在 go 文件里 import 依赖包 之后，在第一次构建程序时，就会拉取依赖包的 最新版本 到本地环境上。
如果咱们应用 docker 或 k8s 这种每次都会 从新构建 环境的公布形式时，那么每次都会 go get 到最新的依赖包。
而这种部署形式是有问题的，因为谁也不晓得最新的依赖包批改了哪些内容。如果每次可能 拉取指定 的版本，那么就能够解决这个问题了，这就是 go mod 所解决的问题。
在 go 1.11 之前也有相似的版本解决方案，比方 像 dep 或者 vendor。起初 golang 官网在 1.11 推出了对应的版本管理工具: go module，也就是咱们常常在我的项目里看到的 go mod 文件。
在这个文件里记录了以后我的项目里所有的依赖包名以及对应的 版本号 ，后续在构建编译时，就会依据 对应的版本号 去拉取依赖包。
gomod 文件的创立
命令: go mod init 我的项目名
比方，我的我的项目是 manage, 那么就能够这样应用：
go mod init manage此时就会在以后我的项目下生成 gomod 文件：
留神, 如果以后的我的项目是要给内部应用的，最好是配合代码 仓库命名，比方
go mod init github.com/lincoln/manage 以便其余我的项目能够 go get 援用失去。
依赖包的版本生成
下面的命令只是生成一个 gomod 文件，至于依赖包的版本号信息临时是还没有生成的，能够应用上面 2 个命令进行获取:
命令 1：go get 包名如果依赖包比拟多，那么 go get 就比拟麻烦了。能够应用另外一个命令：
命令 2：go mod tidy这个命令将会扫描所有咱们 import 到的包，并生成对应的记录到 gomod 文件里。
此时，咱们看到了一条 依赖包以及版本号 的信息记录。
这里的 v2.1.0 是因为援用的 go-cache 包在 github 上曾经打标签了，所以有 v2.1.0 相似的字样呈现，前面有 incompatible 是因为 go-cache 包的命名没有遵循官网标准，所以加了 incompatible 加以辨别。
如果援用的包没有打过标签，那就有其余的版本记录生成规定, 比方
v0.0.0-20210501091049-10806f459f65
就示意 版本号 + 日期 + 主分支 最新的 commit 哈希值 前缀。
此外，咱们还发现除了 gomod 文件之外，还有 gosum 文件。此文件次要是用来记录依赖包的 hash 值 ， 避免 部署到新环境时，从新拉取的包与之前本地拉取的包 不统一。
gomod 文件的应用技巧
1. 援用分支最新的包
默认 状况下，go mod tidy 将会拉取主分支的 最新代码 作为版本记录。
如果咱们有多个我的项目在同时开发，假如都是在 develop 分支上时。
为了能拉取到对应的分支代码，咱们能够手动批改 gomod 援用包的版本名字，替换为对应的 分支名，比方改为:
require github.com/patrickmn/go-cache develop 而后应用 go mod tidy 命令，此时就会主动的获取 develop 分支的最新代码了。（注：此处只是演示，并不实在存在 go-cache 的 develop 分支）
2. 援用本地开发的代码
golang 是依据 gomod 文件来构建程序的，如果咱们援用了其余我的项目代码，那每次就得先提交到代码仓库，而后从新构建 gomod 文件能力援用到新的代码。
为了能间接 援用本地 正在开发的包，又不频繁提交代码，咱们能够应用上面这个命令
replace github.com/patrickmn/go-cache => 本地我的项目包的地址 这样就能够在构建我的项目时，应用本地开发的包了, 等到所有我的项目都开发结束，再最初 从新构建 gomod 文件。
3. 查看依赖包的历史版本
应用 go mod tidy 命令时总会拉取最新版本的依赖包，但当咱们只想 import 某个 历史版本 时，就能够应用上面的命令来获取历史版本号了:
go list -m -versions github.com/patrickmn/go-cache 执行后果：
github.com/patrickmn/go-cache v1.0.0 v2.0.0+incompatible v2.1.0+incompatible而后当咱们想援用 v1.0.0 时，就能够这样改写了:
require github.com/patrickmn/go-cache v1.0.0go module 其余命令
go list -m all：列出以后我的项目包名以及所有依赖到的包
go mod vendor: 将援用的包都 生成 到以后我的项目的 vendor 包下，这样能够不必每次从新构建时去拉取对应的包，间接退出到本人的 git 代码仓库治理中, 间接 git pull 即可。
另外，有点要留神的就是，如果咱们在 gomod 文件里 手动增加 了某个依赖包，但理论在我的项目里 并没有应用 到这个依赖包时，那么在执行 go mod tidy 构建时，就会 主动删除 这个依赖包的相干记录。