GO依赖管理演进

GOPATH ->GO Vendor -> Go Module

作用

不同环境（项目）依赖的版本不同
控制依赖库的版本

GOPATH

环境变量 $GOPATH 目录结构 bin 项目编译的二进制文件 pkg 项目编译的中间产物，加速编译 src 项目源码项目代码直接依赖src下的代码 go get 下载最新版本的包到src目录下弊端无法实现package的多版本控制

Go Vendor

项目目录下新增vendor文件，所有依赖包副本形式放在$ProjectRoot/vendor下依赖寻址方式: vendor => GOPATH 通过每个项目引入一份依赖的副本，解决了多个项目需要同一个package依赖的冲突问题。弊端无法控制依赖的版本更新项目又可能出现依赖冲突，导致编译错误（比如依赖版本不同代码更新）

GO Module

通过go.mod文件管理依赖包版本通过go get/go mod指令工具管理依赖包功能：定义版本规则和管理项目依赖关系

依赖管理三要素

配置文件，描述依赖 go.mod
中心仓库管理依赖库 Proxy
本地工具 go get/go mod

依赖配置-version

语义化版本

${MAJOR}.${MINOR}.${PATCH}

v1.3.0 v2.3.0

${MAJOR}大版本

${MINOR}新增函数或功能(需要在该MINOR版本下保持兼容)

${PATCH}代码修复

基于commit伪版本

vx.0.0-yyyymmddhhmmss-abcdefgh1234 v0.0.0-20220101081311-c38fb59326b7

依赖配置-indirect

没有直接导入的依赖会在尾部用// indirect来进行标识

依赖配置-incompatible

主版本2+模块会在模块路径增加/vN 后缀。对于没有go.mod文件并且主版本2+的依赖，会+incompatible （可能会存在依赖大版本冲突）

依赖分发-回源(直接依赖github svn ...)
依赖分发-Proxy
依赖分发-变量GOPROXY

GOPROXY="https://proxy1.cn,https://proxu2.cn,direct"

服务站URL列表，“direct”标识源站

寻找依赖顺序 Proxy1->Proxy2->Direct

工具

-go get

go get example.org/pkg(包地址) 不加后面@xxx就是直接下载该包

@update 默认 (效果和不加一样)
@none 删除依赖
@v1.1.2 tag版本，语义版本
@23dfdd5 特定的commit
@master 分支的最新commit

-go mod

go mod +

init 初始化，创建go.mod文件
download 下载模块到本地缓存
tidy 增加需要的依赖，删除不需要的依赖

Go依赖管理 | 青训营笔记