Go依赖管理 ｜ 青训营笔记

依赖管理

GOPATH

• 项目代码直接依赖src下的代码
• go get 下载最新版本的包到src目录下 弊端: 无法实现package的多版本控制 eg: A和B都依赖于某一package的不同版本

Go Vendor

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

Go Module

定义版本规则和管理项目依赖关系

• 通过go.mod文件管理依赖包版本
• 通过go get/go mod指令工具管理依赖包

依赖管理三要素

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

module code  // 依赖管理基本单元

go 1.20 // 原生库

require ( // 单元依赖
	github.com/gin-gonic/gin v1.9.0
	github.com/go-redis/redis/v8 v8.11.5
	github.com/kirinlabs/HttpRequest v1.1.1
	谷歌.golang.org/grpc v1.53.0-dev
	谷歌.golang.org/protobuf v1.30.0
	gorm.io/driver/sqlite v1.5.0
	gorm.io/gorm v1.25.0
)

依赖配置 - version

• 语义化版本 ${MAJOR}.${MINOR}.${PATCH}
• 基于commit伪版本 vX.0.0-yyyymmddhhmmss-abcdefgh1234

依赖配置 - indirect A->B->C

• A->B 直接依赖
• A->C 间接依赖

依赖配置 - 依赖图

最终会选择C的1.4版本, 要选择最低的兼容版本

依赖分发 - 回源

• 无法保证构建稳定性 增加 / 修改 / 删除软件版本
• 无法保证依赖可用性 删除软件
• 增加第三方压力 代码托管平台负载问题

依赖分发 - Proxy

GOPROXY="A,B,direct" 表示A和B都没能找到依赖, 则回源站寻找依赖

工具 - go get go get example.org/pkg

• @update 默认
• @none 删除依赖
• @v1.1.2 tag版本, 语义版本
• @23dfdd5 特定的commit版本
• @master master分支最新的commit

工具 - go mod go mod

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

这篇好文章是转载于：学新通技术网