这是我参与[第五届青训营]伴学笔记活动的第3天。 本次我的笔记记录的是GOPATH、Go vendor、Go Module的浅析，如有不太恰当的地方欢迎批评指正！ GOPATH
GOPATH是Go语言支持的一个环境变量，value是Go项目的工作区。 目录有以下结构:
src:存放Go项目的源码；
pkq:存放编译的中间产物，加快编译速度;
bin:存放Go项目编译生成的二进制文件。
GOPATH管理的弊端
在 GOPATH 的 $GOPATH/src 下进行 go 文件或源代码的存储，我们可以称其为 GOPATH 的模式，这个模式拥有一些弊端.
- A. 无版本控制概念. 在执行go get的时候，你无法传达任何的版本信息的期望，也就是说你也无法知道自己当前更新的是哪一个版本，也无法通过指定来拉取自己所期望的具体版本。
- B.无法同步一致第三方版本号. 在运行 Go 应用程序的时候，你无法保证其它人与你所期望依赖的第三方库是相同的版本，也就是说在项目依赖库的管理上，你无法保证所有人的依赖版本都一致。
- C.无法指定当前项目引用的第三方版本号. 你没办法处理 v1、v2、v3 等等不同版本的引用问题，因为 GOPATH 模式下的导入路径都是一样的，都是github.com/foo/bar。
在gopath管理模式下，如果多个项目依赖同一个库，而这个库为适应多个项目而存在不同版本，由于GOPATH无法同时实现多版本控制，这不能满足对不同项目依赖需求。所以，go vendor出现了。
GO VENDOR
go vendor就是将依赖的包，特指外部包，复制到当前项目下的vendor目录下，这样go build的时候，go会优先从vendor目录寻找依赖包。
优势：因为将第三方依赖完全和工程整合，完全本地化，使得项目构建速度快。
问题：放弃了依赖重用，使得冗余度上升。同一个依赖包如果不同工程想重用，都必须各自复制一份在自己的vendor目录下。
GO MODULE
GOMODULE模式下所有依赖的包存放在GOPATH/pkg/mod目录下，所有第三方文件放在GOPATH/bin目录下，且工程项目可以放在GOPATH路径之外，但要求项目中需要有go.mod文件（该文件通过go mod init命令初始化可以生成）。
GOMODULE模式和GOPATH模式一样都指定了依赖包存放的位置，而不是如vendor模式放入项目内，区别在于GOMODULE的go.mod文件中记录了所依赖包的具体版本，既实现了项目之间重用依赖包，且解决了GOPATH模式下不同项目无法依赖同一个包的不同版本的问题。
GO MODULE命令
- go mod init：初始化当前文件夹，创建go.mod文件，事实上，如果你的环境中GO111MODULE=on，使用类似goland的工具创建工程会自动生成go.mod
- go mod tidy：包整理（多的删去、少的拉取），使用之前自然是import了需要的库了
- go mod download：下载依赖到本地（默认为 GOPATH/pkg/mod 目录）
