1、概述
大多数语言都有“依赖”、“包”等概念，Go语言的依赖处理经历了几次变革
最早的时候，Go所依赖的所有的第三方库都放在GOPATH这个目录下面
从v1.5开始开始引入vendor模式，如果项目目录下有vendor目录，那么go工具链会优先使用vendor内的包进行编译、测试等
从v1.11开始，引入了Go Module 作为依赖解决方案，到v1.14宣布Go Module已经可以用于生产环境，到v1.16版本开始Go Module默认开启
2、GOPATH介绍
2.1 GOPATH目录
GOPATH是什么，输入如下命令查看
# go env GOPATH
GOPATH="/Users/ssgeek/go"
进入到该目录下，目录结构如下
# cd `go env GOPATH`
# tree -L 2 .
.
├── bin
│ ├── dlv
│ ├── go-outline
│ ├── gomodifytags
│ ├── gopkgs
│ ├── goplay
│ ├── gopls
│ ├── gotests
│ ├── impl
│ └── staticcheck
├── pkg
│ ├── mod
│ └── sumdb
└── src
└── github.com
...
三个目录中存放的文件说明如下
bin //用来存放编译后的可执行文件
pkg //用于存放编译后生成的归档文件
src //用来存放go源码文件
2.2 GOPATH的缺点
在使用GOPATH的模式下，我们需要将应用代码存放在固定的$GOPATH/src目录下，并且如果执行go get来拉取外部依赖会自动下载并安装到$GOPATH目录下
第三方套件只要不是官方库，都需要放置在GOPATH/src的路径下才可以使用
go get最常用在当我们想用别人公开在GitHub上的套件，可以帮我们从网络clone到GOPATH/src里面。虽然这样很方便，但是会发现GOPATH/src下会很复杂，除了有你自己开发的代码目录，同时也包含其他第三方库的专属目录
我们给不同的项目设置不同的GoPath，优点非常明显：
便于管理项目，每个项目都是不同的GoPath，这对于我们管理多个Golang项目而言，能够非常清晰的处理项目结构。如果我们把所有项目都放在同一个GoPath的src包下，那么项目的结构就会变得非常混乱，难以管理
但是当我们需要依赖第三方的包的时候，不同的项目设置不同的GoPath的缺点也非常明显：
- 第三方依赖的包和我们自己的
Golang包混在一起，会给我们的项目文件管理带来一定的麻烦 - 不同的
GoPath都需要下载依赖，那么磁盘中重复的依赖就会非常多，会占用我们大量的磁盘空间
3、GO Module介绍
为了解决GOPATH的问题，因此官方在1.11开始推出了Go Modules的功能。Go Modules解决方式很像是Java看到Maven的做法，将第三方库储存在本地的空间，并且给项目代码去引用
3.1 设定GO111MODULE环境变量
总共可以设置三种不同的值
- auto
默认值，go命令会根据当前目录来决定是否启用modules功能。需要满足两种情形：
该目录不在GOPATH/src/下
当前或上一层目录存在go.mod文件
- on
go命令会使用modules，而不会去GOPATH目录下查找。
- off
go命令将不会支持module功能，寻找依赖按照以前GOPATH的做法去寻找
目前1.16版本默认将这个参数设置成on，而且可能之后的版本会弃用掉GO111MODULE，因此建议要开发Go项目时就不再使用GOPATH了，而是采用Go Modules的做法，因此建议都设定为on
采用Go Modules，下载下来的第三方依赖就位于GOPATH/pkg/mod目录下
3.2 初始化mod
go mod init <module name>
<module name>可填可不填，不填的话预设就是默认的文件名称go.mod
在此文件中可以写以下几个关键字：
- module
定义模组路径
- go
定义go语言version
- require
指定依赖，预设是最新版，可以指定版本号
- exclude
排除该依赖和其版本
- replace
使用不同的依赖版本并替换原有的依赖版本注解
indirect代表被间接导入的依赖包
假设现在我要引入GitHub上的gin-gonic/gin的依赖，如下定义：
module myProject
go 1.16
require github.com/gin-gonic/gin v1.6.3
再执行以下指令：
go mod xxx
会将需要的依赖安装在GOPATH/pkg/mod目录里面
gin@v1.4.0 gin@v1.6.3 gin@v1.7.1
除了go.mod之外，go命令还维护一个名为go.sum的文件，其中包含特定模块版本内容的预期加密哈希
go命令使用go.sum文件确保这些模块的未来下载检索与第一次下载相同，以确保项目所依赖的模块不会出现意外更改，无论是出于恶意、意外还是其他原因。 go.mod和go.sum都应检入版本控制。
go.sum不需要手工维护，所以可以不用太关注
只要有开启go modules功能，go get 就不会像以前一样在GOPATH/src下放置依赖，而是会放在GOPATH/pkg/mod里面，并且go.mod会写好引入
3.3 go mod命令
常用
go mod init：初始化go mod， 生成go.mod文件，后可接参数指定 module 名，上面已经演示过。
go mod download：手动触发下载依赖包到本地cache（默认为$GOPATH/pkg/mod目录）
go list -m -json all：以 json 的方式打印依赖详情
其他
go mod graph： 打印项目的模块依赖结构
go mod tidy ：添加缺少的包，且删除无用的包
go mod verify ：校验模块是否被篡改过
go mod why： 查看为什么需要依赖
go mod vendor ：导出项目所有依赖到vendor下
go mod edit ：编辑go.mod文件
4、总结
GoPath所引出的问题，就是因为第三方类库的包所导致的，所以在有了GoModule之后，GoPath和GoModule就分别负责不同的职责，共同为Golang项目服务
GoPath用来存放我们从网上拉取的第三方依赖包
GoModule用来存放我们自己的Golang项目文件，当自己的项目需要依赖第三方的包的时候，我们通过GoModule目录下的一个go.mod文件来引用GoPath目录pkg包下的mod文件夹下的第三方依赖即可
这样以来，既解决了原来只能局限在GoPath目录src包下进行编程的问题，也解决了第三方依赖包难以管理和重复依赖占用磁盘空间的问题