这是我参与「第五届青训营 」伴学笔记创作活动的第2天
一、关于Go modules Go Modules 终极入门 参考URL: blog.csdn.net/EDDYCJY/art…
Go modules 是 Go 语言中正式官宣的项目依赖解决方案，Go modules（前身为vgo）于 Go1.11 正式发布，在 Go1.14 已经准备好，并且可以用在生产上（ready for production）了，Go 官方也鼓励所有用户从其他依赖项管理工具迁移到 Go modules。
Go modules 是 Go 语言的依赖解决方案，发布于 Go1.11，成长于 Go1.12，丰富于 Go1.13，正式于 Go1.14 推荐在生产上使用。
因为为了更愉快的使用go，我个人建议还是不要考虑太老版本的go了。至少 Go1.13起步！ 🤩
Go moudles 目前集成在 Go 的工具链中，只要安装了 Go，自然而然也就可以使用 Go moudles 了，而 Go modules 的出现也解决了在 Go1.11 前的几个常见争议问题：
Go 语言长久以来的依赖管理问题。
“淘汰”现有的 GOPATH 的使用模式。
统一社区中的其它的依赖管理工具（提供迁移功能）。
- GOPATH 我们输入go env命令行后可以查看到 GOPATH 变量的结果，我们进入到该目录下进行查看，如下：
go ├── bin ├── pkg └── src ├── github.com ├── golang.org ├── google.golang.org ├── gopkg.in .... 1 2 3 4 5 6 7 8 9 GOPATH目录下一共包含了三个子目录，分别是：
bin：存储所编译生成的二进制文件。 pkg：存储预编译的目标文件，以加快程序的后续编译速度。 src：存储所有.go文件或源代码。在编写 Go 应用程序，程序包和库时，一般会以GOPATH/src目录下 ，并且如果执行go get来拉取外部依赖会自动下载并安装到$GOPATH目录下。
- 为什么弃用 GOPATH 模式 在 GOPATH 的 $GOPATH/src 下进行 .go 文件或源代码的存储，我们可以称其为 GOPATH 的模式，这个模式，看起来好像没有什么问题，那么为什么我们要弃用呢，参见如下原因：
GOPATH 模式下没有版本控制的概念，具有致命的缺陷，至少会造成以下问题：
在执行go get的时候，你无法传达任何的版本信息的期望，也就是说你也无法知道自己当前更新的是哪一个版本，也无法通过指定来拉取自己所期望的具体版本。
在运行 Go 应用程序的时候，你无法保证其它人与你所期望依赖的第三方库是相同的版本，也就是说在项目依赖库的管理上，你无法保证所有人的依赖版本都一致。
你没办法处理 v1、v2、v3 等等不同版本的引用问题，因为 GOPATH 模式下的导入路径都是一样的，都是github.com/foo/bar。
Go 语言官方从 Go1.11 起开始推进 Go modules（前身vgo），Go1.13 起不再推荐使用 GOPATH 的使用模式，Go modules 也渐趋稳定，因此新项目也没有必要继续使用GOPATH模式。
- Go Modules基本使用（Go mod 使用记录） 在 Go modules 中，我们能够使用如下命令进行操作：
命令 作用 go mod init 生成 go.mod 文件 go mod download 下载 go.mod 文件中指明的所有依赖 go mod tidy 整理现有的依赖 go mod grap 查看现有的依赖结构 go mod edit 编辑 go.mod 文件 go mod vendo 导出项目所有的依赖到vendor目录 go mod verify 校验一个模块是否被篡改过 go mod why 查看为什么需要依赖某模块 go.mod 可以让你摆脱GOPATH对项目的约束，同时也是解决GoLand问题的核心。
初始化项目 使用 go mod init 初始化一个 go.mod 文件
go mod init 1 找到项目依赖(整理依赖包) 使用 go mod tidy 找到项目依赖，并写入到 go.mod
go mod tidy 1 如果想缓存到vendor目录
go mod vendor 1 更新已有包版本 如果我们想要更新一个已在 go.mod 文件列出的包，可以使用 go get -u PKG_PATH 如，要更新 github.com/gookit/filter 到最新版本：
