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 模式。

它有三个可选值:offonauto,默认值是auto

  1. GO111MODULE=off禁用模块支持,编译时会从GOPATHvendor文件夹中查找包。

  2. GO111MODULE=on启用模块支持,编译时会忽略GOPATHvendor文件夹,只根据 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

image-20210316171010002

文件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文件,那么这个文件又是什么?

image-20210316171039541

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

关于我

作者博客|文章首发

最后

本文到此结束,希望对你有帮助 😃

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

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

wechat.png

本作品采用《CC 协议》,转载必须注明作者和本文链接
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!