小编给大家分享一下GoPath模式和GoMoudle模式的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
gopath是什么
GOPATH 是什么，相信已经不用我再多说什么了。大家深受摧残多年，应该已经有所体会。在v.1.11版本之前，安装GO肯定要在环境变量中配置GoPath,我们可以简单的将其理解成是工作目录。目录结构如下
-- bin 存放编译后生成的二进制可执行文件
-- pkg 存放编译后生成的 .a 文件
-- src 存放项目的源代码，可以是你自己写的代码，也可以是你 go get 下载的包
将你的包或者别人的包全部放在 $GOPATH/src 目录下进行管理的方式，我们称之为 GOPATH 模式。
GOPATH 根本没有版本的概念，如果你所应用的库需要升级，那就是全局升级，所以涉及这个库的服务在下一次编译中都会使用新的库，这是一件很危险的事情。版本管理非常重要，自己应该管理好自己的引用库。
当其他的开发者get到源码进行修改的时候，你无法保证他下载的包是不是你所期望的版本，这及有可能导致服务出错，且很难查找原因。
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。
GO111MODULE=off禁用模块支持，编译时会从GOPATH和vendor文件夹中查找包。
GO111MODULE=on启用模块支持，编译时会忽略GOPATH和vendor文件夹，只根据 go.mod下载依赖。
GO111MODULE=auto，当项目在$GOPATH/src外且项目根目录有go.mod文件时，自动开启模块支持。
go mod 出现后， GOPATH（肯定没人使用了） 和 GOVENDOR 将会且正在被逐步淘汰，但是若你的项目仍然要使用那些即将过时的包依赖管理方案，请注意将 GO111MODULE 置为 off。
具体怎么设置呢？可以使用 go env 的命令，如我要开启 go mod ，就使用这条命令
go env -w GO111MODULE="on"
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 是以h2:开头的字符串，表示生成checksum的算法是第一版的hash算法（sha256）。
go.mod 和 go.sum 是 go modules 版本管理的指导性文件，因此 go.mod 和 go.sum 文件都应该提交到你的 Git 仓库中去，避免其他人使用你写项目时，重新生成的go.mod 和 go.sum 与你开发的基准版本的不一致。
相比gopath的方式，go mod的好处显而易见。你不必为了版本依赖费劲头脑，模块化自动帮你做好了。这就有点C#中Nuget的味道，node的npm的感觉。开发者不应为了这种事情操心，而应该专注于编码问题。
常用
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模式的，方式也很简单，大家动动小手，一百度就可以。当然正式的切换肯定是需要领导同意的，毕竟工作系统随意切换还是有风险的。
以上是“GoPath模式和GoMoudle模式的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
