Go语言中的包管理工具之Go Modules的使用

GoLang 中常用的包管理的方式

常用的有三种
- Go Path
- Go Vendor
- Go Modules

关于 Go Modules

1 ) 概述

Go的包管理，经过社区和官方的共同努力下，最终在百家争鸣后
Go官方在 2018.8 推出了go 1.11版本中的Go Modules，并且很快成为一统江湖的包管理方式
Go Modules已经成为目前最主流的包管理工具
需要注意的是，go从1.13版本开始 Go Modules 被默认选择使用
在go的1.11 和 go的1.12 版本中，需要我们手动开启 Go Modules

管理方式	版本	发布时间
GoPath 模式	< 1.5 版本	2009.11.10
Go Vendor	>= 1.5 版本	2015.8.19
Go Modules	>=1.11 版本	2018.8.24

关于Go Modules，我们必须要搞明白下面这几个问题
- 第一个是 Go Modules 的用法
- 第二个是 go.mod 文件是什么时候生成的，有什么作用，具体有哪些内容
- go.sum 文件是什么时候生成的，有什么作用，具体有哪些内容，其中的哈希值是怎么计算的, 怎么实现包校验的

2 ) Go Modules 用法

在go1.11的时候就发布了 Go Modules, 但是功能默认是关闭的，直到go的1.13版本才开始开启
所以在go 1.11 和 go 1.12 版本中，我们需要通过go提供的变量，GO111MODULE 来开启 Go Modules
- 这里跟之前的 Go Vendor 里面开启 govendor 的环境变量
- 即：GO15VENDOREXPERIMENT 这个环境变量类似
GO111MODULE 也属于go的阶段性变量
- 通常在某个功能发布之初的几个版本，是需要手动去开启的
- 等稳定下来，被开发者接受之后，会在后续的版本中默认开启
GO111MODULE，它有三个值
- 第一个是 on, 它表示开启 Go Modules
- 第二个是 off 它表示关闭 Go Modules
- 第三个是 auto
当项目路径在Go Path目录外部时
- 如果你设置的是 auto 的话，我们这个 GO111MODULE 就会被设置成 on
那当项目路径在 Go Path内部时
- 即使存在 go.mod 文件, 也会将 GO111MODULE 设置成 off
在Unix环境下(Linux, MacOS)
- 需要把 GO111MODULE 设置成 on，然后通过 export 将这个环境变量导出
- export GO111MODULE=on
在Windows环境
- 我们可以通过 set命令将 GO111MODULE 设置成 on
  - $ set GO111MODULE=on
- 当然直接修改 Go 的 Path 环境变量也是可以的
还有一种方式是两种类型的操作系统都可以支持的
- 我们可以通过 $ go env -w GO111MODULE=on
- 加上 -w 参数来将这个 GO111MODULE 设置成on
- 如果没有任何输出就是正常了
- 注意，我们在执行上面这个命令的时候可能会抛出一个 warning
- 这个waring的意思, 就是说我们不能通过这个 go env 指令去覆盖我们环境变量的设置
- 也就是说，如果我们在环境变量里面已经设置了 GO111MODULE 这个环境变量
- 我们就需要去改环境变量里面这个 GO111MODULE 这个值，而不能通过命令的方式去设置
- 通常这些环境变量可能会在
  - /etc/profile 文件里
  - 或者是 ~/bash.profile文件里
  - 或者是 /etc/.bashrc 文件里
  - 或者是 ~/.bashrc 文件里
  - 或者是 ~/.profile 文件里
- 需要注意的是，仅仅设置 GO111MODULE，这个环境变量为on
- 并不能代表项目就使用了 Go Modules 方式来管理包
我们使用 $ go mod init 将项目初始化成一个 Go Modules 工程
这个命令需要在项目的根目录下执行执行成功后，在当前目录下面生成一个 go.mod 的文件

3 ) go mod 的具体用法

需要准备好环境，go版本需要 >= 1.11
- 如果go的版本没有到 1.13, 就需要将 GO111MODULE 设置成 on
- 查看我们当前使用的go版本，通过 $ go version
之后，可能需要设置go代理
- 如果我们是开发环境，我们可以直接在这个编辑器IDE上进行设置，比如 GoLand
- 在这个编辑器上，file / settings里面，就可以对这个go的环境变量进行配置
- 可以找到Go Modules
  - 需要勾选这个 Enable Go modules integration
  - 填入 Environment, 设置 Go Path 和 Go Proxy
  - GOPROXY https://goproxy.cn/,https://mirrors.aliyun.com/goproxy/,direct
  - 这里 direct的意思是当从上面两个途径无法获取，就从源码获取
  - GOPRIVATE 这个变量是内部包的配置，一般在公司部署的私网内的地址
在生产环境中的设置
- 比如在Unix环境下
  - 我们可以通过将下面
  - export GOPROXY https://goproxy.cn/,https://mirrors.aliyun.com/goproxy/,direct
  - 放入 /etc/profile 里面
- 在Windows下，通过 set 指令设置 GOPROXY
  - $ set GOPROXY=https://goproxy.cn/,https://mirrors.aliyun.com/goproxy/,direct
- 也支持 $ go env -w GOPROXY=https://goproxy.cn/,https://mirrors.aliyun.com/goproxy/,direct

4 ) 工程示例

$ mkdir go-mod-test && cd go-mod-test 目录, 仅作为示例
$ go mod init go-mod 创建一个go-mod工程目录
可看到里面生成一个 go.mod 文件

在这里就可以编写程序了，$ touch main.go

package mainimport 'github.com/astaxie/beego/logs'func main() {logs.Warn('demo')
}

现在解决第三方包引用的问题, 到工程根目录中执行
$ go mod tidy
- 这时候就会自动找到项目以来的包
- 解决工程中包依赖的关系，如果缺少包，则下载并维护信息到 go.mod
- 如果没有用的，则移除
执行 go run main.go 正常输出
在 go.mod 下又生成了 go.sum的文件
- 这里写的是工程所有直接依赖包和间接依赖包
go mod download
- 下载依赖包到本地缓存
- 如果 go.mod 和 go.sum 已经包含依赖包的信息，而且依赖包还没有下载到本地
- 这个指令会把依赖包下载到本地
go mod vendor
- 为了兼容 go vendor 模式
- 在 go mod 发布之前，go vender 使用是比较普遍的
- go mod 也支持将依赖包通过我们这个go mod vender 指令复制到我们项目 vendor 目录当中
- 可以看到我们当前这个项目里面是没有 vendor 目录的
- 那我们在这个项目的根目录里面，执行 go mod vendor
  - 刷新一下，我们可以看到它就为我们生成的一个vendor目录
  - 在 vendor 里面还有一个 modules.txt 文件
  - 这个文件记录了我们当前这个venders里面依赖的包以及包的版本信息。
那上面四个指令是最常用的，还有一些其他指令
- 比如 $ go help mod 可以看到我们go mod支持的一些指令
- 这里面包括还有一些 go mod graph，go mod why, 以及 go mod verify
- 这些是查看和校验依赖的一些指令
- go mod edit, 我们可以用来编辑这个 go.mod 文件, 平时也很少使用，我们了解即可

5 ) 关于 go.mod 和 go.sum

接下来需要重点了解两个文件
- 1 ) go.mod
  - 这个文件里面主要是描述了模块的一些属性
  - 包括它的其他模块的go版本的依赖的信息
    - 里面第一行就是 module 的name，这个name一般使用 git仓库上的路径
    - 第二行是版本信息，项目依赖的最低版本要求，只是获取当前go版本的信息
    - 第三行，require 指令，包含导入的非工程项目内的包
    - 后面都是 require
    - 工程依赖包有直接依赖包，如beego, 还有间接依赖包
      - 所谓间接依赖包就是直接依赖包的依赖包
      - 如果beego中需要依赖一些包，有一些包没有 go.mod 文件则会添加到工程的 go.mod中
      - 并且生成一个尾版本号
        尾版本号格式: 版本号 - UTC的提交时间(提交到github的时间) - commit 哈希的前缀
- 2 ) go.sum
  - 在触发项目编译后生成，如 go build，go run等指令
  - 里面详细罗列了项目直接或间接依赖的所有模块的版本
  - 每一条包含了模块依赖的路径，导入的版本和哈希值
  - 每个依赖包有可能有多条信息
    - 一种是有 go mod 标识，后面哈希值是 go.mod 的哈希
    - 另一种没有，则后面的哈希是包的每一个文件的哈希
  - 实现包的校验
    - 当我们拿到某个项目的源代码，并尝试在构地进行构建的时候
    - go命令会从本地缓存中去查找所有 go.mod 中记录的依赖包
    - 并且会计算出本地依赖包的哈希值
    - 然后与我们 go.sum 文件中的记录进行对比, 也就是说
    - 它会检测某地缓存中使用的依赖包的版本是否满足项目中 go.sum 文件中期望的版本
    - 如果不满足，就说明本地缓存目录当中的依赖包版本和项目中go.sum文件记录的版本的哈希值是不一致的
    - 这个时候构建就会被拒绝。
    - 这样就可以确保相同的依赖包在任何环境使用这些依赖包的源码，它都是一样的
    - 依赖包中任何一个文件，包括 go.mod 的改动，都会改变它整体的哈希值
    - 在 go.sum 中记录额外的 go.mod 的文件，就是为了在计算这个依赖树的时候
    - 不用去下载完整的依赖包版本，只根据 go.mod 就可以计算出这个依赖信息
    - 主要目的就是加快这个依赖包的校验
    - 那每条记录的哈希值, 都有一个表示的哈希算法的一个h1的哈希算法。
    - 这个哈希算法是由SHA-256计算出来的
    - 那模块版本的SHA-256的哈希值主要是用来校验当前缓存的模块
    - 用来准备go在今后的操作过程中，保证项目中所有的依赖的那些模块版本都不会被篡改
    - 在每次我们构建项目发现有模块缺少的时候，如果在缓存中不存在
    - 那就需要下载并且计算这个包的哈希
    - 并且添加到 go.sum当中，如果缓存中已经存在，就需要匹配 go.sum 中已有的记录
    - 需要注意的是，在每次缺少模块的时候，也就是说我们需要的依赖包
    - 它不在 go.sum 文件当中，而且是一个公网可下载的包
    - go命令就会去go的校验数据库获取模块的校验和，它的默认配置是这个 sum.golang.org
    - 我们也可以使用中国大陆官方的这个校验数据库 sum.golang.google.cn
    - 这个校验数据库，会查询并获取这个模块的校验和
    - 如果下载的这个模块的校验和与它计算出来的校验和不匹配
    - 那我们的 go mod 命令就没办法成功执行, 那如果能够匹配
    - 就会把校验和写到go.sum文件当中
    - 这里有三种情况，它不会对依赖包做哈希校验
      - 第一种, 就是我们配置的这个 GOPRIVATE 匹配到的包
        当我们配置的 GO PRIVATE 这个环境变量被我们 GO PRIVATE 匹配到的这些模块包就不会check sum校验
        GO PRIVATE 这个变量主要是用来设置我们内部的一些包, 不走 GO PROXY 配置的代理
        因为内部的包，基于代码安全的考虑，都不会上传到我们的github上面
      - 第二个, 就是我们可以通过 go mod vendor 命令将依赖包全部下载到我们工程的根目录下的 vendor 目录下面
        它可以用来做离线编译
        打包到 vendor 目录中的包也不会再做哈希校验
      - 第三个, 就是 GOSUMDB 设置为off的时候
        所有的包都不会做包校验，相当于关闭了我们这个go sum的校验
- 需要注意的是，同一个模块版本的数据只会缓存一份。那所有其他模块呢都会共享使用。
- 如果你希望清除当前已经缓存的模块的版本数据，可以执行这个 $ go clean -modcache

6 ) go.mod 和 go.sum 对比

为什么我们看到的 go.sum 文件中记录的依赖包的版本数量会比go.mod 文件要多很多
go.mod 记录的是直接依赖的依赖包版本，直接依赖包版本，不含 go.mod 文件时，才记录构建依赖赖的版本
go.sum则是要记录构建依赖到的所有依赖包的版本，它包括直接依赖包和间接依赖包

7 ）关闭依赖包校验

如果不希望进行依赖包校验，可以关闭
可以将这个GOSUMDB 设置成 off 就可以关闭我们当前的 go sum 校验
- $ go env -w GOSUMDB=off
- 或将环境变量添加到 /etc/profile

8 ) 依赖包的存储对比

Go Path 模式下和 Go Modules 模式下，依赖包的存储路径是不一样的
在 Go Path 模式下，依赖包存储在这个 $GOPATH/src
这个目录下只保存特定依赖包的一个版本
我们通过 go get 下载的包，也包含完整的仓库信息的，也就是包含了 .git 的目录
而我们在 GOMODULES 模式下，依赖包会存储在这个 $GOPATH/pkg/mod 下面
- 而且这个目录下面可以存储特定依赖包的多个版本
- 每个版本会占用一个目录，那这个目录里面，只包含依赖包文件，不包含 .git 的目录