这是我参与「第五届青训营 」伴学笔记创作活动的第 3 天。
- Vendor 是当前项目中的一个目录，其中存放了当前项目依赖的副本。在Vendor机制下，如果当前项目存在Vendor目录，会优先使用该目录下的依赖，如果依赖不存在，会从GOPATH中寻找。但vendor无法很好解决依赖包的版本变动问题和一个项目依赖同一个包的不同版本的问题，下面我们看一个场景
- 如图项目A依赖pkg b和c，而B和C依赖了D的不同版本，通过vendor的管理模式我们不能很好的控制对于D的依赖版本，一旦更新项目，有可能带来。归根到底vendor不能很清晰的标识依赖的版本概念。下面，go module就应运而生了。
- Go Modules 是Go语言官方推出的依赖管理系统，解决了之前依赖管理系统存在的诸如无法依赖同一个库的多个版本等问题，go module从Go 1.11 开始实验性引入，Go 1.16 默认开启；我们一般都读为go mod。
- 完善的依赖管理一般都需要4要素。首先模块路径用来标识一个模块，从模块路径可以看出从哪里找到该模块，如果是github前缀则表示可以从Github 仓库找到该模块，依赖包的源代码由github托管，如果项目的子包想被单独引用，则需要通过单独的init go。mod文件进行管理。 下面是依赖的原生sdk版本 最下面是单元依赖，每个依赖单元用模块路径+版本来唯一标示。
- gopath和govendor都是源码副本方式依赖，没有版本规则概念，而gomod为了放方便管理则定义了版本规则， 分为语义化版本和；其中语义化版本包括，不同的MAJOR 版本表示是不兼容的 API，所以即使是同一个库，MAJOR 版本不同也会被认为是不同的模块；MINOR 版本通常是新增函数或功能，向后兼容；而patch 版本一般是修复 bug ；而基于commit的为版本包括，基础版本前缀是和语义化版本一样的；时间戳 (yyyymmddhhmmss), 也就是提交 Commit 的时间，最后是校验码 (abcdefabcdef), 包含 12 位的哈希前缀；每次提交commit后 Go 都会默认生成一个伪版本号。
