为了确保一致性构建，Go语言中引入了go.mod文件来标记每个依赖包的版本，在构建过程中go命令会下载go.mod中的依赖包，下载的依赖包会缓存在本地，以便下次构建。
在进行go语言项目开发的时候，会依赖3种类型的库包：
- 内置的标准库包，在goroot/src目录下，也就是我们安装目录的src目录下(类似于python的bin目录)
- 第三方库包（git上开源的）
- 项目中的库包，也就是项目中的其他目录。自己调用自己写的函数方法
生成go.mod文件
确保go版本>=1.11
在项目的根目录下，执行go mod init xxxx
xxxx为对应的项目名称。
例如：我们创建一个geecache的项目，在命令行执行go mod init geecache
此时，项目目录就产生了go.mod
go.sum
为了解决Go module的这一安全隐患，Go开发团队在引入go.mod的同时也引入了go.sum文件，用于记录每个依赖包的哈希值，在构建时，如果本地的依赖包hash值与go.sum文件中记录得不一致，则会拒绝构建。
- 执行
go mod tidy命令，会生成go.sum文件
go.sum文件详解
go.sum文件中每行记录由module 名， 版本和哈希组成，并由空格分开，格式如下：
<module> <version>[/go.mod] <hash>
例如：上述go.sum中就记录了github.com/golang/protobuf这个依赖v1.3.3版本的哈希值：
github.com/golang/protobuf v1.3.3 h1:gyjaxf+svBWX08ZjK86iN9geUJF0H6gp2IRKX6Nf6/I=
github.com/golang/protobuf v1.3.3/go.mod h1:vzj43D7+SQXF/4pzW/hwtAqwc6iTitCiVSaWz5lYuqw=
通常，每个依赖包版本会包含两条记录:
- 第一条为该依赖包版本整体（所有文件）的哈希值，
- 第二条仅表示该依赖包版本中
go.mod文件的哈希值
如果该依赖包版本没有go.mod文件，则只有第一条记录。如上面的例子中，v1.3.3 表示该依赖包版本整体，而v1.3.3/go.mod表示该依赖包版本中go.mod文件。
依赖包版本中任何一个文件（包括go.mod）改动，都会改变其整体哈希值，此处再 **额外记录依赖包版本 **的go.mod文件主要用于计算依赖树时不必下载完整的依赖包版本，只根据go.mod即可计算依赖树。go.mod只需要记录直接依赖的依赖包版本，只在依赖包版本不包含go.mod文件时候才会记录间接依赖包版本。而go.sum则是要记录构建用到的所有依赖包版本。
校验
假设我们拿到某项目的源代码并尝试在本地构建，go命令会从本地缓存中查找所有go.mod中记录的依赖包，并计算本地依赖包的哈希值，然后与go.sum中的记录进行对比，即检测本地缓存中使用的依赖包版本是否满足项目go.sum文件的期望。
如果校验失败，说明本地缓存目录中依赖包版本的哈希值和项目中go.sum中记录的哈希值不一致，go命令将拒绝构建。 这就是go.sum存在的意义，即如果不使用我期望的版本，就不能构建。
当校验失败时，有必要确认到底是本地缓存错了，还是go.sum记录错了。 需要说明的是，二者都可能出错，本地缓存目录中的依赖包版本有可能被有意或无意地修改过，项目中go.sum中记录的哈希值也可能被篡改过。
当校验失败时，go命令倾向于相信go.sum，因为一个新的依赖包版本在被添加到go.sum前是经过GOSUMDB（校验和数据库）验证过的。此时即便系统中配置了GOSUMDB（校验和数据库），go命令也不会查询该数据库。
校验和数据库
环境变量GOSUMDB标识一个checksum database，即校验和数据库，实际上是一个web服务器，该服务器提供查询依赖包版本哈希值的服务。
该数据库中记录了很多依赖包版本的哈希值，比如Google官方的sum.golang.org则记录了所有的可公开获得的依赖包版本。除了使用官方的数据库，还可以指定自行搭建的数据库，甚至干脆禁用它（export GOSUMDB=off）。
如果系统配置了GOSUMDB，在依赖包版本被写入go.sum之前会向该数据库查询该依赖包版本的哈希值进行二次校验，校验无误后再写入go.sum。
如果系统禁用了GOSUMDB，在依赖包版本被写入go.sum之前则不会进行二次校验，go命令会相信所有下载到的依赖包，并把其哈希值记录到go.sum中。
