解析Golang中的GoPath和GoModule

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中的GoPath和GoModule内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论