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？

我们之前说过，所有的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
1.14
go

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

例如下面的go.mod文件：

module go_module_demo

module go_module_demo

go 1.14

require (
    github.com/astaxie/beego v1.12.1
    github.com/go-sql-driver/mysql v1.5.0
)

我们在这个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属性：