为什么依赖管理那么重要？ 项目不可能基于标准库从0开始搭建。前人栽树后人乘凉。学习如何管理依赖库，能让项目搭建事半功倍

go的依赖管理

为什么依赖管理那么重要？

• 项目不可能基于标准库从0开始搭建。前人栽树后人乘凉。学习如何管理依赖库，能让项目搭建事半功倍

项目依赖管理经历过三个阶段

1. GOPATH

   • 使用环境变量“$GOPATH”，通过环境变量确定Go项目的工作区
   • 因为依赖和项目文件都放在src目录下。所以某个版本的依赖库有且仅存在唯一一个特定版本存在。如果有个项目依赖不同版本的依赖库，GOPATH对此束手无措。

2. Go Vendor

   • 在项目目录（GOPATH）下增加vendor目录
   • 给每个项目引入一份依赖库的副本，解决不同项目依赖不同版本的问题。
   • 但还不能很好的管理复杂多层的依赖管理树

3. Go Modules !!!

   • 内置在go工具链里（go 1.11以上）
   • 通过本地工具go get 命令通过中心仓库获取依赖库
   • 通过go mod工具管理依赖库
   • 使用go.mod文件描述项目依赖

但在这里不详细介绍每个阶段的详细使用，只对目前广泛使用的Go Module依赖管理进行说明。

在此之前先说一下go的一些基本命令：

• go run xxx包名

  • go运行包，但不会生成任何二进制文件在项目下

• go build xxx包名

  • go编译包并生成可执行文件

Go Modules 的详细使用

第一步：go mod init 初始化项目模块

• go mod init xxx 命令让目录下生成go.mod文件

以下是不含任何外部依赖库的go.mod文件

1
2
3

module goTest

go 1.21.0

包含单元名"goTest" 和 go原生库版本 1.21.0

• 至此，一个依靠go mod的项目依赖已经基本搭建好了。只需非常简单的一步。

第二步： 通过go get 获取依赖库

1

go get github.com/stretchr/testify

上面的命令将通过Proxy从github获取对应的依赖库文件

此时，观察项目目录将会发现go.mod文件发生改变，同时有文件go.sum生成。

go.mod文件：

1
2
3
4
5
6
7

module goTest

go 1.21.0

require (
	github.com/stretchr/testify v1.8.4 // indirect
)

require里是单元依赖 后面跟版本号v1.8.4 indirect指明没有直接导入该模块的包，是间接依赖。

go.sum文件：

1

github.com/stretchr/testify v1.8.4/go.mod h1:sz/lmYIOXD/1dqDmKjjqLyZ2RngseejIcXlSw2iwfAo=

除了依赖库名和版本号，还有以h1开头的hash字符串。

题外话：go work

在项目编写中，需要用到workspace工作区，将项目文件放在一个目录下。但没有合适的工具，直到发现自带的工具go work

• go work init命令初始化当前目录为工作区。在当前目录下生成go.work文件

1

go 1.21.0

目前只有go版本号

• go work use [-r] xxx路径 ：go work use将路径里含有go.mod的Go Module加入到go.work中。（-r命令会递归查找路径下的所有子目录）

1
2
3
4
5
6
7

go 1.21.0

use (
	./goTest
	./online_dict
	./proxy
)

这是使用了go work use命令后的go.work文件。 包含了所有的含go.mod的模块。

现在，只需要在go.work目录下的工作区使用go run/build + 包名就可以直接运行/编译对应的包了。

写在最后

这些只是我的go工具链使用的一些小小心得。还有很多不甚了解的地方，请多多包涵。希望在后面项目的训练中更好的熟悉go的工具使用。

参考:

• 我的掘金文章