这是我参与「第五届青训营 」伴学笔记创作活动的第 2 天

本篇内容

• Go语言依赖管理的发展：GOPATH和go vendor

Go依赖管理的发展

GOPATH

Overview

GOPATH是最早的Go语言依赖管理方式。GOPATH是作为Go语言的环境变量配置的，通过go env命令就可以查看。简单地，一个GOPATH包含bin、pkg、src三个目录：

• bin：存放go build构建的可执行二进制文件
• pkg：存放各种静态链接库
• src：存放项目源码和第三方依赖源码

GOPATH的问题

• 所有项目代码都必须放在GOPATH/src下，或者将项目路径导入GOPATH。一般GOPATH都在C盘下，项目全扔进去容易炸C盘，而且环境变量乱动也会出问题...
• 依赖也存放在GOPATH/src下
• GOPATH没有版本的概念，如果出现依赖版本的冲突容易导致项目无法运行。

考虑一个依赖拓扑。依赖A和C均依赖于一个上游库D，但是A依赖版本为1.14而C依赖1.16，且由于D的bug，两个库均不能依赖对方的依赖版本。像下面的架构图：

那么GOPATH无论拉取1.14版本还是1.16都会造成项目无法运行。事实上由于项目内部（AC均在一个项目）和主机上各种项目（AC不属于同一个项目的依赖）的依赖都非常复杂，这种情况非常常见，而且几乎是无法解决的，因此带来了很大不便。

Vendor

为解决这种问题，go在之后的版本中推出了vendor机制，但依然没能顺利解决依赖管理的问题。go vendor在项目的根目录中添加了一个vendor目录，缓存了当前项目的依赖，从而解决了不同项目依赖冲突的问题；同时使用vendor.json管理依赖清单，解决了远程clone后安装依赖复杂的问题。但是问题也是显而易见的：每个项目倾向于维护自己独有的一套依赖，造成了每个项目的依赖库都非常庞大，即使依赖版本相同也需要缓存两份（除非回到GOPATH/src）；而且vendor依然需要手动管理编写依赖清单文件，容易产生问题。但vendor中的一些思想也是非常进步的，并在之后持续发挥作用；此时go module应运而生，成为了如今go语言依赖管理的最佳方式。

下一篇内容

• go module的原理和应用
• go的标准项目架构