Go中依赖管理 | 青训营笔记

64 阅读1分钟

依赖管理

GOPATH

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

20230513160021.png

Go Vendor

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

20230513160303.png

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
	google.golang.org/grpc v1.53.0-dev
	google.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 间接依赖

依赖配置 - 依赖图

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

依赖分发 - 回源

20230513161702.png

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

依赖分发 - Proxy

20230513161820.png 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 增加需要的依赖, 删除不需要的依赖