一、GOPATH的概念

       GOPATH 是 Go 语言中使用的一个环境变量，它使用绝对路径提供项目的工作目录（也称为工作区）, 是存放 Golang 项目代码的文件路径, GOPATH 适合处理大量 Go语言源码、多个包组合而成的复杂工程。

        工作目录是一个工程开发的相对参考目录，好比当你要在公司编写一套服务器代码，你的工位所包含的桌面、计算机及椅子就是你的工作区。

        工作区的概念与工作目录的概念也是类似的。如果不使用工作目录的概念，在多人开发时，每个人有一套自己的目录结构，读取配置文件的位置不统一，

二、GOPATH的使用 

GOPATH目录一般为：

1、bin 存放编译生成的二进制文件。比如 执行命令 go get github.com/google/gops，bin目录会生成 gops 的二进制文件。

2、pkg 其中pkg下面以下三个文件夹。

•  XX_amd64: 其中 XX 是目标操作系统，比如 mac 系统对应的是darwin_amd64, linux 系统对应的是 linux_amd64，存放的是.a结尾的文件。
•  mod: 当开启go Modules 模式下，go get命令缓存下依赖包存放的位置
•  sumdb: go get命令缓存下载的checksum数据存放的位

3、src 存放golang项目代码的位置

 

 如下是一个完整的Go项目的开发目录：

my-go                 // my-go为GOPATH目录
  -- bin
     -- myApp1        // 编译生成
     -- myApp2        // 编译生成
     -- myApp3        // 编译生成
  -- pkg                             依赖包编译后的*.a文件//
  -- src
     -- MyApp1        // 项目1
        -- models
        -- controllers
        -- others
        -- main.go 
     -- MyApp2        // 项目2
        -- models
        -- controllers
        -- others
        -- main.go

三、造成问题

        在使用 GOPATH 模式下，我们需要将应用代码存放在固定的$GOPATH/src目录下，且如果执行go get使用第三方类库的时候会自动下载并安装到$GOPATH目录下。 项目的Golang代码，和第三方的Golang文件混在一起, 每个如果项目都需要同样的依赖，那么我们就会在不同的GoPath的src中下载大量重复的第三方依赖包，这同样会占用大量的磁盘空间

GOPATH 的缺点

1. 必须指定目录，
2. go get 命令的时候，无法指定获取的版本
3. 引用第三方项目的时候，无法处理v1、v2、v3等不同版本的引用问题，因为在GOPATH 模式下项目路径都是 github.com/foo/project
4. 无法同步一致第三方版本号，在运行 Go 应用程序的时候，无法保证其它人与所期望依赖的第三方库是相同的版本。

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

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

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

1. 第三方依赖的包和我们自己的Golang包混在一起，会给我们的项目文件管理带来一定的麻烦。
2. 不同的GoPath都需要下载依赖，那么磁盘中重复的依赖就会非常多，会占用我们大量的磁盘空间。

所以，设置一个GoPath目录，解决依赖重复的问题，设置不同的GoPath目录，解决Golang项目结构混乱的问题，这本身就是个有争议性的问题。

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

 

四、参考

一文搞懂GOPATH 与 GO Modules 

Golang中的GoPath和GoModule