解析Golang中的GoPath和GoModule

本篇文章向大家介绍《解析Golang中的GoPath和GoModule》，主要包括module、Path，具有一定的参考价值，需要的朋友可以参考一下。

GoModule无法下载国外的依赖包问题
在Golang中，有两个概念非常容易弄错，第一个就是GoPath，第二个则是GoModule，很多初学者不清楚这两者之间的关系，也就难以清晰地了解项目的整体结构，自然也就难以编写结构清晰的代码。

什么是GoPath？

什么是Gopath？在我的上一篇博客Golang环境安装&IDEA开发Golang中，曾经提到过GoPath的概念。
GoPath是Golang的工作空间，所有的Go文件，都需要放在GoPath下的src目录下才能够编译运行，所以我提议不要直接配置全局的GoPath目录，否则会非常难以管理所有的Golang项目。

但是在另一篇博客Golang连接MySQL数据库之CRUD中，我也提到过，我们在项目中使用第三方类库的时候，可以使用go get命令从网下直接拉去第三方类库的包，而拉取下来的包就会直接下载到我们的GoPath目录下的src包下。

这样就导致了一个问题，我们自己的Golang代码，和第三方的Golang文件混在了一起，这对于我们管理Golang项目的包显然是非常麻烦的，而且每个如果项目都需要同样的依赖，那么我们就会在不同的GoPath的src中下载大量重复的第三方依赖包，这同样会占用大量的磁盘空间。

我们给不同的项目设置不同的GoPath，优点非常明显：

便于管理项目，每个项目都是不同的GoPath，这对于我们管理多个Golang项目而言，能够非常清晰的处理项目结构。如果我们把所有项目都放在同一个GoPath的src包下，那么项目的结构就会变得非常混乱，难以管理。

但是当我们需要依赖第三方的包的时候，不同的项目设置不同的GoPath的缺点也非常明显：

第三方依赖的包和我们自己的Golang包混在一起，会给我们的项目文件管理带来一定的麻烦。
不同的GoPath都需要下载依赖，那么磁盘中重复的依赖就会非常多，会占用我们大量的磁盘空间。
所以，究竟是设置一个GoPath目录，解决依赖重复的问题，还是设置不同的GoPath目录，解决Golang项目结构混乱的问题，这是一个有争议性的问题。

为了解决这所有的问题，Golang最终引入了GoModule的概念。

什么是GoModule？

GoModule是Golang在1.11版本初步引入的概念，在1.12版本中正是开始使用，所以如果需要使用GoModule，那么需要保证你的Golang的版本在1.12或以上。
另外需要说一下，Golang1.11和1.12版本虽然已经引入了GoModule的概念，但是GoModule是默认不开启的，如果需要开启，那么需要配置一个环境变量：GO111MODULE=on，默认是off。

而在Golang1.13及以上的版本中，GoModule的默认配置为auto，即GoModule会通过你的目录下是否有go.mod文件来判断是否开启GoModule。所以Golang1.13+的版本中我们就不需要配置GO111MODULE属性了。
所以如果你使用GoModule，那么就直接使用Golang1.13+的版本好了！

那么究竟什么是GoModule？

其实说得直白一下，GoModule就是一个用来取代GoPath的Golang的工作空间。
我们之前说过，所有的Golang的文件，都需要放在GoPath目录下才能进行正确的编译和运行，而有了GoModule之后，那么我们就可以把文件放在GoModule目录下，而放在GoModule目录下的Golang文件，也可以正确地编译运行。

那么我们有了GoModule之后，GoPath是不是就可以被舍弃了？

不是的！

我们之前说过，GoPath所引出的问题，就是因为第三方类库的包所导致的，所以我们在有了GoModule之后，GoPath和GoModule就分别负责不同的职责，共同为我们的Golang项目服务。

GoPath我们用来存放我们从网上拉取的第三方依赖包。
GoModule我们用来存放我们自己的Golang项目文件，当我们自己的项目需要依赖第三方的包的时候，我们通过GoModule目录下的一个go.mod文件来引用GoPath目录src包下的第三方依赖即可。

这样依赖，既解决了原来只能局限在GoPath目录src包下进行编程的问题，也解决了第三方依赖包难以管理和重复依赖占用磁盘空间的问题。

总而言之，在引入GoModule之后，我们不会直接在GoPath目录进行编程，而是把GoPath作为一个第三方依赖包的仓库，我们真正的工作空间在GoModule目录下。

GoModule的设置

既然搞清楚了GoPath和GoModule之间的区别，那么GoModule又该怎么配置呢？一个目录怎么才能算是一个GoModule目录了。

很简单，我们直接使用go mod init 模块名称命令对目录进行初始化操作，即可将这个目录设置为GoModule目录。
我们在F:\GoModule目录下创建一个文件夹，名字为：go_module。
然后通过cmd命令提示符进入该目录，执行go mod init 模块名称初始化命令。

当初始化命令执行完毕之后，会在go_module目录下生成一个go.mod文件，该文件就是用来引入GoPath目录下的第三方依赖的文件。

初始化之后的go.mod文件

module go_module

go 1.14

当我们需要引入GoPath目录下的第三方依赖包的时候，只需要在go.mod目录下添加依赖名称，GoModule就会自动帮我们把第三方依赖包下载到GoPath目录下。

例如下面的go.mod文件：

我们在这个go.mod文件中引入了两个依赖，分别是：beego框架 v1.12.1版本和mysql驱动 v1.5.0版本。

而如果我们使用IDE进行开发的话，那么可以直接创建一个GoModule项目，这样的话IDE会自动帮我们生成所需要的文件，而且在使用依赖的包的时候，IDE还会自动帮我们加入依赖和下载依赖，这会省去我们大量的时间，而且可以不用再去记忆依赖的具体包名和版本号。
GoModule无法下载国外的依赖包问题
这是一个很多开发者都碰到过的问题，对于国外的依赖包无法直接通过网络进行下载，这显然会让开发者非常难受，所以Golang也引入了另一个属性：GOPROXY，我们只需要在环境变量中配置GOPROXY=https://goproxy.io即可解决GoModule无法下载国外的依赖包问题。
当然，也可以通过IDE来配置，这样省的在电脑系统的环境变量配置太多难以管理。

在IDEA中配置GOPROXY属性：

原文链接：https://blog.csdn.net/qq_45193304/article/details/105491864

今天关于《解析Golang中的GoPath和GoModule》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！