GOPATH,go vendor,go mod解析

GOPATH

早期Go语言使用GOPATH来进行依赖管理。安装Go语言之后,我们需要配置环境变量,GOROOTGOPATHGOROOT代表Go语言的安装目录,GOPATH代表你的工作路径。

GOPATH下的目录结构

  • – bin 存放编译后生成的二进制可执行文件
  • – pkg 存放编译后生成的 .a 文件
  • – src 存放项目的源代码,可以是你自己写的代码,也可以是你 go get 下载的包
GOPATH
├── bin
├── pkg
└── src
    ├── projectA
    ├── projectB
    └── projectC

将你的包或者别人的包全部放在 $GOPATH/src 目录下进行管理的方式,我们称之为GOPATH模式。

使用 GOPATH 管理的缺点

版本管理问题

GOPATH 根本没有版本的概念,GOPATHsrc下只能有一个版本存在,所以不能实现多版本控制。

如果你所应用的库需要升级,那就是全局升级,所以涉及这个库的服务在下一次编译中都会使用新的库,这是一件很危险的事情。版本管理非常重要,自己应该管理好自己的引用库。

协同开发问题

当其他的开发者get到源码进行修改的时候,你无法保证他下载的包是不是你所期望的版本,这及有可能导致服务出错,且很难查找原因。

GOVENDOR

为了解决 GOPATH 方案下不同项目下无法使用多个版本库的问题,Go v1.5 开始支持 vendor 。我们之前是所有项目都放到GOPATHsrc目录下进行管理,所有项目的依赖都在这里寻找。并且只能存在一个版本。但是每个项目可能引用的第三方库的版本不一样,我们需要满足多版本控制。

于是,现在可以在每个项目下建立vector目录,每个项目所需的依赖都只会下载到自己vendor目录下,项目之间的依赖包互不影响。

如果该项目要查找引用的包,那么会按照如下顺序进行搜索

  • 先搜索当前包下的vendor目录
  • 向上级目录搜搜,直到src下的vendor目录
  • GOROOT目录下搜索
  • GOPATH目录下搜索
 .
└── GOPATH
    ├── bin
    ├── pkg
    └── src
        ├── projectA
        │   ├── handler
        │   ├── server.go
        │   └── vendor
        ├── projectB
        │   ├── handler
        │   ├── server.go
        │   └── vendor
        └── projectC
            ├── handler
            ├── server.go
            └── vendor

使用 GO VENDOR 管理的缺点

假设一个Project依赖AB两个package,然后A依赖第三方的package v1B依赖第三方的package v2,这就会导致冲突。

仍然需要在GOPATH目录下。

GO MOD

之后Go引入了go modgo mod不在依赖$GOPATH目录,因此我们可以在其他地方创建项目,而不一定要在$GOPATH/src目录下。

go mod模式可以手动开启关闭,通过GO111MODULE实现。

  • GO111MODULE=off禁用模块支持,编译时会从GOPATHvendor文件夹中查找包。
  • GO111MODULE=on启用模块支持,编译时会忽略GOPATHvendor文件夹,只根据 go.mod下载依赖。
  • GO111MODULE=auto,当项目在$GOPATH/src外且项目根目录有go.mod文件时,自动开启模块支持。

使用go env查看环境变量,可以看到GO111MODULE=on,说明我启动了go mod模式管理依赖

go env
PS D:\Go\workspaces\src> go env
set GO111MODULE=on
set GOPATH=D:\syz\study\computer_science\Go\workspaces
set GOPROXY=https://goproxy.cn,direct
set GOROOT=D:\Program Files (x86)\go

如何使用go mod

创建一个项目,在此文件夹下输入go mod init初始化(记得开启go mod模式),之后变会使用go mod模式管理。之后,会在你的目录下创建go.mod文件,编译后还会出现go.sum文件。

我们在简单的hello world程序下引入gin框架,可以看到go.sum文件出现了变动,go mod会将所有的依赖包安装在$GOPATH/pkg目录下。

GOPATH,go vendor,go mod解析_第1张图片

go.mod文件

  • 第一行:模块的引用路径
  • 第二行:项目使用的 go 版本
  • 第三行:项目所需的直接依赖包及其版本
module test

go 1.13

require github.com/gin-gonic/gin v1.7.7

go.sum文件

每一行都是由 模块路径模块版本哈希检验值 组成,其中哈希检验值是用来保证当前缓存的模块不会被篡改。hash 是以h1:开头的字符串,表示生成checksum的算法是第一版的hash算法(sha256)。

github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/gin-contrib/sse v0.1.0 h1:Y/yl/+YNO8GZSjAhjMsSuLt29uWRFHdHYUb5lYOV9qE=
...

有的包可能有两行

<module> <version> <hash>
<module> <version>/go.mod <hash>

那些有两行的包,区别就在于hash值不一行,一个是 h1:hash,一个是 go.mod h1:hash

h1:hashgo.mod h1:hash两者,要不就是同时存在,要不就是只存在 go.mod h1:hash。那什么情况下会不存在 h1:hash 呢,就是当Go认为肯定用不到某个模块版本的时候就会省略它的h1 hash,就会出现不存在 h1 hash,只存在 go.mod h1:hash 的情况。

注意

如果你开启了go mod模式,但是又没有go mod init,那么是无法进行依赖管理的,也不会按照GO PATH的方法进行依赖查找。

参考

  • (206条消息) golang中使用GOPATH模式和GoModule(gomod)模式的区别_SunkingYang的博客-CSDN博客_gopath和gomodule
  • 19. 一文搞懂 Go Modules 前世今生及入门使用 - 王一白 - 博客园 (cnblogs.com)

你可能感兴趣的:(Golang,golang,开发语言,后端)