这里的 markdown 用着是真不习惯
Go 安装、升级、版本替换
安装 brew
https://brew.sh/
安装 go
brew install go
升级 go
brew upgrade go
版本替换(比如我团队用的是 go1.17,不过我安装的是 1.19,那么需要 go 降级回去)
# 安装 1.17
brew install go@1.17
# 取消 link 现在 1.19 版本的 go
brew unlink go
# 强制 link 1.17 版本的 go
brew link --force go@1.17
# go version 查看是否替换成功
Go 包管理迭代历程
(摘自文章:https://www.modb.pro/db/211633)
复用代码一直是软件开发中提升效率的重要方法,大型工程的开发离不开积累的各种开源、闭源的依赖库. go 语言也不例外,go 的包管理随 go 的诞生后,经过了一系列的迭代. 迭代历程如下:
- 2012年3月 Go 1 发布,此时没有版本的概念
- 2013年 Golang 团队在 FAQ 中提议开发者保证相同 import path 的兼容性,后来成为一纸空文
- 2013年10月 Godep
- 2014年7月 glide
- 2014年 有人提出 external packages 的概念,在项目的目录下增加一个 vendor 目录来存放外部的包
- 2015年8月 Go 1.5 实验性质加入 vendor 机制
- 2015年 有人提出了采用语义化版本的草案
- 2016年2月 Go 1.6 vendor 机制 默认开启
- 2016年5月 Go 团队的 Peter Bourgon 建立委员会,讨论依赖管理工具,也就是后面的 dep
- 2016年8月 Go 1.7: vendor 目录永远启用
- 2017年1月 Go 团队发布 Dep,作为准官方试验
- 2018年8月 Go 1.11发布 Modules 作为官方试验
- 2019年2月 Go 1.12发布 Modules 默认为 auto
- 2019年9月 Go 1.13 版本默认开启 Go Mod 模式
Go 包管理模式
GOPATH 模式
早期 go 使用的是 GOPATH 模式,GOPATH 内存在三个文件夹:
- bin:存放可执行的二进制文件,当我们把 $GOPATH/bin 配置在环境变了 PATH 中后,可以在全局位置使用bin 中的可执行文件
- pkg:存储编译的中间产物 .a
- src:存储源码
GOPATH 模式下所有的项目以及依赖的包都需要存放在 $GOPATH/src 中,项目依赖包会在 $GOPATH/src 或者 $GOROOT/src 中查找
GOPATH 模式存在的版本管理问题:
所有的项目以及它们依赖的包都存放在 $GOPATH/src,并且依赖包之间没有版本的概念,所有的项目依赖同一个包,当某个项目的依赖包需要升级时,那么就是全局升级,其他依赖该包的项目在下次编译的时候都会使用新版本的依赖包,这可能导致其他项目出现不兼容问题
Vendor 模式
Go 1.5 版本添加了 vendor 模式,每个项目都有单独的一个 vendor 目录,该目录下存储项目的依赖包
这使得多个项目之间的依赖包隔离,不会有全局升级的风险
由于 vendor 目录在项目目录下,打包的时候可以直接将项目的所有依赖包 vendor 目录和源代码一起打包,但多个项目的话会存在大量重复的依赖包
Vendor 模式依赖包的查找顺序:
1.查找当前项目的 vendor 目录
2.查找上一目录的 vendor 目录
3.一层层往上,直到 $GOPATH/src/vendor,都没有就报错