依赖管理
这是我参与「第五届青训营 」伴学笔记创作活动的第 3天
背景
Go依赖管理演进
现主要用Go Module
GOPATH
缺陷：A项目依赖V1版本，B项目依赖V2版本，无法实现package多版本控制
GO Vendor
解决了GoPath的问题，A项目和B项目先去自己的vendor文件中寻找依赖包，这样项目与项目之间就不会起冲突。
弊端：
它解决了项目之间的冲突，但是A项目进行更新的时候，如果更新后新包和旧包不兼容，则无法解决。而且没有依赖控制的版本
GO Module
依赖管理三要素
依赖配置
go.mod
依赖管理基本单元：导入其它地方的包，也能是github上项目的包
原生库：可能不同的项目对应的go的版本不同
单元依赖：前面是包名 后面是版本号，这样可以唯一指定。indirect代表非直接依赖。
version
版本控制主要是分两种：
- 语义化版本
MAJOR代表大的版本，可以理解为不同的MAJOR之间是版本不兼容、代码隔离的。
MINOR代表小的函数增加，这必须在MAJOR兼容的情况下添加功能。
PATCH代表bug的修复。 - 基于commit的伪版本
版本前缀和语义化版本是一样的。
中间的是提交commit的时间戳。
后面的是提交时哈希码的前缀
incompatible
当语义版本大于等于2的时候，例如v3.0.2，应当在包名后面跟上v2后缀。
对于没有go.mod文件并且主版本2+的依赖，会在后面加上一个+incompatible，代表可能会有一些不兼容的代码逻辑。
依赖分发
如果我们直接去依赖Github或者SVN这种第三方的源会有以下的问题：
- 无法保证构建稳定性，因为作者可以随时随地的增加或者删除自己的代码。
- 无法保证依赖可用性，因为作者删了 你就没得用了，项目就崩溃了。
- 增加第三方压力，Github本来是没想着把项目这么用的，直接依赖会导致高并发的访问，给他们带来巨大压力并违背初衷。
Proxy
我们可以将代码管理到Proxy中，这样就直接从Proxy中下载和访问，稳定且可靠
