在Go语言编程中，我们经常会接触到依赖管理。简单来讲，这是对项目所需外部包的管理，包括确定所需外部包及其正确版本，并确保在构建和测试项目时其存在。
基础依赖管理则涉及到添加、更新和删除依赖包，锁定依赖包版本等工作。尽管看似琐碎，但这些工作对项目开发至关重要。
但实际上，go的依赖管理让人一言难尽，甚至可以说乱成一团。官方推出了好几种管理机制，比如gopath、vender、dep等，但都用起来不是那么顺手。到了Go 1.11版本，推出了go mod，虽然稍微好些，但和maven比起来，还是差了好几条街。
更让人费解的是，Go居然没有像maven、pip那样的官方依赖包站点。第三方包可以在任意开源站点发布，这就导致了一堆问题，比如下载地址、版本管理、包说明文档等。
由于没有统一的下载地址，Go的解决方案是把包名就当做包的下载地址。虽然很多包都发布在github.com，但也有很多包用其他站点发布，比如k8s.io、bazil.org、gobot.io等等。这就导致无法建立加速镜像站点，国内的加速都只能通过代理的方式。
包名的格式也有限制，只要是会被其他项目用到的包，名字就得是下载地址。就算是公司内部的私有包也不能例外，否则就得人工维护依赖。
包的文档格式和API说明也没有标准，直到go官方推出了pkg.go.dev站点，才统一了文档风格和包检索。但奇怪的是，这个站点只提供包信息和展示，包还是得在各自的站点发布。
吐槽归吐槽，要用的时候我们还是得用go语言，下面我会给大家讲一讲go的那些管理机制。
Gopath
GOPATH是Go的一个重要环境变量，被称为工作目录。在Go 1.5版本之前，通过执行go get ${packageName}命令，我们可以下载依赖包。这个命令总是下载最新版本的依赖包，并且这些依赖包都会被存放在${GOPATH}/src目录下，但是并没有版本控制。
当我们使用import命令导入依赖包时，会按照以下路径查找：${GOROOT}/src -> ${GOPATH}/src。其中，${GOROOT}/src是Go SDK的安装目录，src文件夹存放了Go的标准库。而${GOPATH}/src则是Go的工作目录，src文件夹存放了所有的Go项目。
需要注意的是，当我们需要导入项目内部模块时，也需要从这些固定路径计算，因此所有项目都必须放在工作目录下，否则会出现找不到依赖的问题。这与其他语言有很大的区别，例如Java和Python都支持从项目路径计算，这意味着项目可以放在任意目录。
例如，如果我们的项目名称是demo，那么导入依赖的方式如下：
import "fmt" // 导入标准库包
import "demo/utils" // 导入项目内的工具模块包, 注意也从绝对路径查找
import "github.com/forgoer/openssl" // 导入外部第三方包fmt是Go语言的标准库，它的源代码位于GOROOT/src目录下。其他非标准库的包，例如你自己编写的包或者第三方包，都应该放在GOPATH/src目录下。这是Go语言的包管理机制决定的，它帮助Go语言在编译时找到所需要的包。
如果你想修改fmt包的代码，你可以直接在GOROOT/src目录下找到fmt包的源代码进行修改。
但是，我不推荐你这样做，因为这样会改变Go语言的标准行为。
如果你只是想使用修改过的fmt包，你可以在GOPATH/src目录下创建一个新的包，然后在新包中导入fmt包，并在新包中添加或修改你需要的功能。这样，你的代码就可以使用修改过的fmt包，而不会影响到其他使用标准fmt包的代码。
Vender
Go 1.5版本引入了一个新的特性，叫做vendor机制。这个机制允许每个项目在其目录下有一个名为vendor的文件夹，用来存放该项目所依赖的包。在执行go build命令时，Go语言会首先在vendor目录下查找依赖，如果没有找到，才会去GOPATH目录下查找。依赖查找的顺序是：${GOROOT}/src -> ${Project}/vendor -> ${GOPATH}/src。
vendor机制的出现主要是为了解决依赖版本管理的问题。
它的基本思想是，每个项目的依赖都可以在自己的目录下独立管理，这样就避免了不同项目之间的依赖冲突。但是，这个机制并没有解决依赖包的版本问题，只是将依赖包放在了独立的目录下。如果你想要固定依赖包的版本，你需要将整个vendor目录一起提交到代码仓库。
这种做法虽然在一定程度上解决了版本管理的问题，但是也带来了一系列新的问题。
首先，vendor目录通常会非常大，提交到代码仓库会占用大量的空间，并且会降低仓库的下载和更新速度。
其次，大量的依赖代码会干扰代码审查，对代码统计和其他性能工具也会产生影响。
最后，对于多人协作的项目来说，管理项目的依赖包，记录版本，获取和存放依赖包等工作会变得更加复杂。从某种意义上说，蛮鸡肋的。
Go mod
它是从Go1.11版本开始引入的模块支持（module）功能的一部分，比起其他依赖管理，挺实用的。GoMod提供了对依赖包的自动获取、版本控制、依赖图分析等功能。
每个项目都会新增一个go.mod文件，用于维护该项目的依赖包信息，包括依赖包的版本号。可以使用go mod init ${ProjectName}命令来创建这个文件，而文件的内容则由Go自动维护。每次下载或升级依赖时，Go都会自动更新这个文件。
要使用go mod，需要先通过环境变量GO111MODULE来启用这个功能。"off"意味着关闭go mod，Go将继续从vendor目录或GOPATH中查找依赖。"on"则表示开启go mod，这时项目必须包含go.mod文件。如果没有设置环境变量，或者设置为"auto"（这是Go 1.13及以后版本的默认模式），那么Go会自动判断是否启用go mod：如果项目不在GOPATH/src目录下，并且包含go.mod文件，那么Go就会启用go mod。
使用GoMod的好处包括：
- 简化依赖管理：你不再需要将所有的依赖复制到你的项目目录下，GoMod会自动为你下载和管理这些依赖。
- 便于协作：当其他开发者克隆你的项目时，他们不需要手动安装所有的依赖，只需要运行
go mod download命令即可。 - 便于版本控制：你可以在
go.mod文件中明确指定依赖的版本，这样就可以避免因为依赖包的更新导致的不兼容问题。 - 提供依赖图分析：通过
go mod graph命令，你可以查看项目的依赖图，了解各个依赖之间的关系。
当然go mod也有其他的操作：
go mod download ：手动触发下载依赖包到本地 cache
go mod graph ：打印项目的模块依赖结构
go mod edit ：编辑 go.mod 文件
go mod verify：校验模块是否被篡改过
go mod why： 查看为什么需要依赖
go mod vendor：导出项目所有依赖到 vendor 下
总的来说，GoMod是一个强大且易用的依赖管理工具，它可以极大地提高Go语言开发的效率和质量。
