2.0 依赖管理
这一章我们主要讲解go的依赖管理， 主要涉及go依赖管理的演进路线和go module实践
依赖指各种开发包
对于hello world以及类似的单体函数只需要依赖原生SDK，而实际工程会相对复杂，我们不可能基于标准库0~1编码搭建，而更多的关注业务逻辑的实现，而其他的涉及框架、日志、driver、以及collection等一系列依赖都会通过sdk的方式引入， 这样对依赖包的管理就显得尤为重要
2.1 Go依赖管理演进
2.1.1 GoPATH
GOPATH是Go语言支持的一个环境变量，value是Go项目的工作区。
目录有以下结构:
src: 存放Go项目的源码；pkg: 存放编译的中间产物，加快编译速度;
bin: 存放Go项目编译生成的二进制文件，
大家想想用gopath依赖管理有 哪些弊端呢?
弊端
如图，同一个pkg，有2个版本，A-> A0,B-> B0.
而src下只能有1个版本存在，那AB项目无法保证都能编译通过。 也就是在gopath管理模式下，如果多个项目依赖同一个库，则依赖该库是同一份代码，所以不同项目不能依赖同一个库的不同版本，这很显然不能满足我们的项目依赖需求。为了解决这问题，govender出现了
2.1.2 GoVendor
Vendor是当前项目中的一个目录，其中存放了当前项目依赖的副本，在Vendor机制下，如果当前项目存在Vendor目录，会优先使用该目录下的依赖，如果依赖不存在，会从GOPATH中寻找。 vendor无法很好解决依赖包的版本变动问题和一个项目依赖同一个包的不同版本的问题，下面我们看一个场景
如图项目A依赖pkg b和c，而B和C依赖了D的不同版本，通过vendor的管理模式我们不能很好的控制对于D的依赖版本，一旦更新项目，有可能带来依赖冲突。
归根结底vendor不能清晰的标识依赖的版本概念原因是：他还是依赖源码。
下面，go mod就应运而生了。
2.1.3 Go Module
Go Modules 是Go语言官方推出的依赖管理系统，解决了之前依赖管理系统存在的诸如无法依赖同一个库的多个版本等问题
G0 module从1.11 开始实验性引入，1.16 默认开启;我们一般都读为go mod，我们也先统一下名称
2.2 依赖管理三要素
那其实完善的依赖管理一般都需要3要素，这里我们先整体介绍下
这里熟悉java的同学，可以类比下maven
