GoPath模式和GoMoudle模式的相爱相杀

相信看我文章的文章的童鞋，golang版本已是1.3版本以上。若是你的版本还停留在1.3如下，那这篇文章能够作为你的提高之法。

go moudle的前世此生

前世-gopath

gopath是什么

GOPATH 是什么，相信已经不用我再多说什么了。你们深受摧残多年，应该已经有所体会。在v.1.11版本以前，安装GO确定要在环境变量中配置GoPath,咱们能够简单的将其理解成是工做目录。目录结构以下

-- bin 存放编译后生成的二进制可执行文件

-- pkg 存放编译后生成的 .a 文件

-- src 存放项目的源代码，能够是你本身写的代码，也能够是你 go get 下载的包

将你的包或者别人的包所有放在 $GOPATH/src 目录下进行管理的方式，咱们称之为 GOPATH 模式。

gopath有什么样的问题？

版本管理问题

GOPATH 根本没有版本的概念，若是你所应用的库须要升级，那就是全局升级，因此涉及这个库的服务在下一次编译中都会使用新的库，这是一件很危险的事情。版本管理很是重要，本身应该管理好本身的引用库。

协同开发问题

当其余的开发者get到源码进行修改的时候，你没法保证他下载的包是否是你所指望的版本，这及有可能致使服务出错，且很难查找缘由。

此生-GoMoudle

go modules 在 v1.11 版本正式推出，在发布的 v1.14 版本中，官方正式发话，称其已经足够成熟，能够应用于生产上。

从 v1.11 开始，go env 多了个环境变量： GO111MODULE ，这里的 111，其实就是 v1.11 的象征标志， go 里好像很喜欢这样的命名方式，好比当初 vendor 出现的时候，也多了个 GO15VENDOREXPERIMENT环境变量，其中 15，表示的vendor 是在 v1.5 时才诞生的。

GO111MODULE 是一个开关，经过它能够开启或关闭 go mod 模式。

它有三个可选值：off、on、auto，默认值是auto。

1. GO111MODULE=off禁用模块支持，编译时会从GOPATH和vendor文件夹中查找包。
2. GO111MODULE=on启用模块支持，编译时会忽略GOPATH和vendor文件夹，只根据 go.mod下载依赖。
3. GO111MODULE=auto，当项目在$GOPATH/src外且项目根目录有go.mod文件时，自动开启模块支持。

go mod 出现后， GOPATH（确定没人使用了） 和 GOVENDOR 将会且正在被逐步淘汰，可是若你的项目仍然要使用那些即将过期的包依赖管理方案，请注意将 GO111MODULE 置为 off。

具体怎么设置呢？可使用 go env 的命令，如我要开启 go mod ，就使用这条命令

go env -w GO111MODULE="on"

go mod 使用

go mod 再也不依靠 $GOPATH，使得它能够脱离 GOPATH 来建立项目

你能够在你电脑的任意位置建立一个文件夹go_demo

使用 go mod 命令初始化，此时目录下只有2个文件，go.mod是执行命令后生成的文件。

go mod init go_demo

文件main.go解释：引入一个now的时间处理库，输出时间

package main

import (
	"fmt"

	"github.com/jinzhu/now"
)

func main() {
	fmt.Println("hello world", now.BeginningOfDay())
}

go.mod内容

module go_demo

go 1.15

require github.com/jinzhu/now v1.1.1

内容解释：

• 第一行：模块的引用路径
• 第二行：项目使用的 go 版本
• 第三行：项目所需的直接依赖包及其版本

---

此时咱们在命令行执行go build进行编译,发现多了一个go.sum文件，那么这个文件又是什么？

go.sum 文件相比go.mod就比较复杂了。虽然内容多，可是也不难理解。

每一行都是由 模块路径，模块版本，哈希检验值 组成，其中哈希检验值是用来保证当前缓存的模块不会被篡改。hash 是以h1:开头的字符串，表示生成checksum的算法是初版的hash算法（sha256）。

---

go.mod 和 go.sum 是 go modules 版本管理的指导性文件，所以 go.mod 和 go.sum 文件都应该提交到你的 Git 仓库中去，避免其余人使用你写项目时，从新生成的go.mod 和 go.sum 与你开发的基准版本的不一致。

---

go mod的好处

相比gopath的方式，go mod的好处显而易见。你没必要为了版本依赖费劲头脑，模块化自动帮你作好了。这就有点C#中Nuget的味道，node的npm的感受。开发者不该为了这种事情操心，而应该专一于编码问题。

go mod 命令使用

经常使用

go mod init：初始化go mod， 生成go.mod文件，后可接参数指定 module 名，上面已经演示过。

go mod download：手动触发下载依赖包到本地cache（默认为$GOPATH/pkg/mod目录）

go list -m -json all：以 json 的方式打印依赖详情

不经常使用

• go mod graph： 打印项目的模块依赖结构
• go mod tidy ：添加缺乏的包，且删除无用的包
• go mod verify ：校验模块是否被篡改过
• go mod why： 查看为何须要依赖
• go mod vendor ：导出项目全部依赖到vendor下
• go mod edit ：编辑go.mod文件

如何看待go moudle并应用于工做

go mode 方式确定是推荐的一种方式，若是不是基于历史项目-使用GOPATH，推荐尽快使用go mod方式，这能让你省去不少糟心的事情。可是若是公司的项目还有很多就是基于gopath方式的，那你也不要着急，gopath的旧项目也是支持切换成go mod模式的，方式也很简单，你们动动小手，一百度就能够。固然正式的切换确定是须要领导赞成的，毕竟工做系统随意切换仍是有风险的。

参考文章

一文搞懂 Go Modules

关于我

做者博客|文章首发

最后

本文到此结束，但愿对你有帮助 😃

若是还有什么疑问或者建议，能够多多交流，原创文章，文笔有限，才疏学浅，文中如有不正之处，万望告知。

更多精彩技术文章汇总在个人 公众号【程序员工具集]】，持续更新，欢迎关注订阅收藏。