如果所有Gopher都抛弃GOPATH构建模式，拥抱Go module构建模式；如果所有legacy Go package作者都能为自己的legacy package加上go.mod；如果所有Go module作者都严格遵守语义版本(semver)规范，那么Go将彻底解决“依赖地狱”问题。
但现实却没那么乐观！Go中的“依赖地狱问题”依然存在。这一篇我们就来聊聊Go中依赖地狱的“发作场景”、原因以及解决方法。
1. 什么是“依赖地狱(dependency hell)”？
“依赖地狱”问题不是某种编程语言独有的问题，而是一个在软件开发和发布领域广泛存在问题。维基百科对该问题的广义诠释是这样的：
当几个软件包对相同的共享包或库有依赖性，但它们依赖于不同的、不兼容的共享包版本时，就会出现依赖性问题。如果共享包或库只能安装一个版本，用户可能需要通过获得较新或较旧版本的依赖包来解决这个问题。反过来，这可能会破坏其他的依赖关系。
在软件开发构建领域，我们会面对同样的“依赖地狱”问题。文字总是很难懂，我们用更为直观的示意图来说明什么是软件构建过程中的“依赖地狱”问题，大家先看看下面这个示意图：
我们看到在这幅图中：包P1依赖包P3 V1.5版本，包P2依赖包P3 V2.0版本，App同时依赖包P1和包P2。于是问题出现了：构建工具在构建App这个应用时需要决策究竟要使用包P3的哪个版本：V1.5还是V2.0？当然这个问题存在的一个前提是：App中只允许包含包P3的一个版本。
如果P3的V1.5与V2.0版本是不兼容的版本，那么构建工具无论选择包P3的哪个版本，App的构建都会以失败告终。开发人员只能介入手工解决，解决方法无非是将P1对P3的依赖升级到V2.0，或将P2对P3的依赖降级为V1.5版本。但P1、P2多数情况下是第三方开源包，App的开发人员对P1、P2包的作者的影响力有限，因此这种手工解决的成功率也不高。
“依赖地狱”(又称为“钻石依赖”问题)由来已久，几十年来各种编程语言都在努力解决这一问题，并也有了几种可以帮助到开发者的不错的方案。我们先来看看Go语言的解决方案。
2. Go的解决方案
在GOPATH构建模式时代，Go构建工具是无法自动解决上述“依赖地狱”问题的。Go 1.11版本引入Go module构建模式后，经过几年的打磨，Go module构建模式逐渐成熟，并已经成为Go构建模式的标准。
Go module构建模式是可以部分解决上述“依赖地狱”问题的。Go module解决这个问题的思路是：语义导入版本(sematic import versioning)，即在包的导入路径上加上包的major version前缀。
使用“语义导入版本”后，Go解决上面那个问题的方案如下图：
我们看到：Go通过打破“App中只允许包含包P3的一个版本”这个前提实现了P1和P2各自使用自己依赖的版本。但这样做的前提是P1和P2依赖的P3版本的major版本号是不同的。在Go中，由于采用语义导入版本机制，major版本号不同的module被视为不同的module，即使它们源于同一个repository(比如上面的源于同一个P3的v1.5和v2.0就被视为两个不同的module)。
当然这种解决方案是有代价的！第一个代价就是构建出来的app的二进制文件size变大了，因为二进制文件中包含了多个版本的P3的代码；第二个代价，可能也算不上代价，更多是要注意的是不同版本的module之间的类型、变量、标识符不能混用，我们以go-redis/redis这个开源项目举个例子。go-redis/redis最新大版本为v8.11.4，没有启用go.mod时的版本为v6.x.x，我们将这两个版本混用在一起：
package main
import (
"context"
"github.com/go-redis/redis"
redis8 "github.com/go-redis/redis/v8"
)
func main() {
var rdb *redis8.Client
rdb = redis.NewClient(&redis.Options{
Addr: "localhost:6379",
Password: "", // no password set
DB: 0, // use default DB
})
_ = rdb
}
Go编译器在编译这段代码时会报如下错误：
cannot use redis.NewClient(&redis.Options{…}) (value of type *"github.com/go-redis/redis".Client) as type *"github.com/go-redis/redis/v8".Client in assignment
即redis v8下的Client与redis Client并非一个类型，即使它们的内部字段相同，也不能混用在一起。
那么，是不是说有了Go module构建机制后，“依赖地狱”问题就彻底从Go开发中被移除了呢？不是的。“依赖地狱”问题依旧存在，下面我们就来看看哪些情况下还会出现此类问题。
3. 哪些情形下“依赖地狱”依旧存在
1) 依赖不带go.mod的legacy Go包
如今Go语言引入Go module已经多年了，但Go社区仍然存在大量legacy的Go包尚未增加go.mod文件。对于这样的go包，Go命令的处理策略大致是这样的：
- 对于尚未打tag的go包，那么就按等同于v0/v1的方式处理
go命令将go包缓存在本地mod cache时，会合成一个go.mod文件，比如：
// $GOMODCACHE/cache/download
go.starlark.net
└── @v
├── list
├── list.lock
├── v0.0.0-20190702223751-32f345186213.mod // 这里是合成的go.mod
├── v0.0.0-20200821142938-949cc6f4b097.info
├── v0.0.0-20200821142938-949cc6f4b097.lock
├── v0.0.0-20200821142938-949cc6f4b097.mod // 这里是合成的go.mod
├── v0.0.0-20200821142938-949cc6f4b097.zip
├── v0.0.0-20200821142938-949cc6f4b097.ziphash
├── v0.0.0-20210901212718-87f333178d59.info
└── v0.0.0-20210901212718-87f333178d59.mod // 这里是合成的go.mod
- 对于已经打了tag的go包且tag的major版本号<2，那么也按等同于v0/v1的方式处理
go命令将这样的go包缓存在本地mod cache时，同样会合成一个go.mod文件，比如：
// $GOMODCACHE/cache/download
pierrec
|-- lz4
| |-- @v
| | |-- list
| | |-- v1.0.1.info
| | |-- v1.0.1.lock
| | |-- v1.0.1.mod // 这里是合成的go.mod
| | |-- v1.0.1.zip
| | |-- v1.0.1.ziphash
- 对于打了tag且tag的major版本号>=2的，Go命令将包下载到mod cache中后，同样会为该go包合成一个go.mod文件，该文件名vX.Y.Z+incompatible.mod，比如下面这个例子：
// $GOMODCACHE/cache/download
pierrec
|-- lz4
| |-- @v
| | |-- list
| | |-- v2.6.1+incompatible.info
| | |-- v2.6.1+incompatible.lock
| | |-- v2.6.1+incompatible.mod // 这里是合成的go.mod
| | |-- v2.6.1+incompatible.zip
| | `-- v2.6.1+incompatible.ziphash
以上三种情况下，合成的.mod文件中的module root path都是不带vN后缀的，无论是否打tag，也不论tag major版本是否>=2，以v2.6.1+incompatible.mod为例，其内容如下：
// v2.6.1+incompatible.mod
module github.com/pierrec/lz4
我们看到，该合成的mod文件中也不包含这个legacy包自身所依赖的第三方包的require代码块。那么依赖lz4这个legacy包的项目如何确定lz4的第三方依赖的版本呢？并且lz4依赖的第三方包的版本记录在哪里呢？我们以app依赖github.com/pierrec/lz4为例，看下面示意图：
go mod命令在做依赖分析时，会根据源码中的import github.com/pierrec/lz4确定lz4的版本，由于没有vN后缀，go命令会找lz4的v2以下的源码中的go.mod，但lz4在这之前都没有添加go.mod，于是只能按照legacy的模式去确定lz4的版本，这里确定的是v2.6.1+incompatible，go命令将其作为app module的直接依赖：
require github.com/pierrec/lz4 v2.6.1+incompatible
之后go命令还会对lz4的依赖做分析，并将其记录到app module的go.mod中，作为indirect依赖：
require github.com/frankban/quicktest v1.14.2 //indirect
将直接依赖的legacy包的第三方依赖记录在自己的go.mod中是为了满足基于go.mod的可重现构建的要求。
好了！我们了解了go命令处理legacy go包的方式，再来看看如果出现“钻石依赖”情况下，Go命令是如何处理的？直接给结论，如下图：
在这幅图中，我们让P1依赖lz4的v1.0.1版本，让P2依赖lz4的v2.6.1+incompatible版本，这两个版本都是legacy（未添加go.mod）下打的tag。那么当app既依赖P1又依赖P2时，go命令会如何选择lz4的版本呢？Go命令简单粗暴的选择了同时满足P1和P2的最小版本：v2.6.1+incompatible。这里Go似乎做了一个假设：legacy包的新版本一定是向前兼容老版本的。对于lz4这个包来说，这个假设是正确的，我们对App的构建与执行不会遇到问题。
但是一旦这个假设不成立，比如：lz4的v2.6.1是一个不兼容v1.0.1的发布，那么App的构建将遇到错误。这种情况go命令是无能为力了，只能进行手工干预！那怎么干预呢？无非以下几种手段：
- 提issue督促P1作者将对lz4的依赖升级到最新v2.6.1版本
这种手段效率低不说，很可能P1的author根本就不会搭理你。
- fork一个P1，自己修改，然后让App依赖你fork后的P1
这种手段可行，但后续就要自己维护一个fork的P1，无形中给自己增加了额外的负担。
- vendor下来，自己修改，在vendor目录下维护
这种手段也可行，但后续只能使用vendor模式构建，且要自己维护一个本地的P1，同样也给自己增加了额外的负担。
那就没有更好的方法了么？真没有！从legacy项目到拥抱go module的项目的过渡过程注定是坎坷的。
2) 采用go module机制的依赖包的冲突问题
看完legacy包后，我们再来看依赖是采用go module机制的包的冲突问题。有了对上面例子理解的基础，理解下面的例子的就更容易了，我们来看下面示意图：
这个例子也很简单，P1和P2都依赖module P3，分别依赖P3的v1.1.0版本和v1.2.0版本，和之前的例子一样，App既依赖P1，也依赖P2，这样就构成了图中右侧的“钻石结构”。不过，Go module的另外一个机制：最小版本选择(MVS)可以很好的解决这个依赖问题。
MVS机制同样是基于语义版本之上的，它会选择满足此App依赖的最小可用版本，这里P3的v1.1.0版本与v1.2.0版本的major版本号相同，因此按照语义版本规范，他们是兼容的版本，于是go命令选择了满足app依赖的最小可用版本为v1.2.0(此时P3的最高版本为v1.7.0，Go命令没有选择最高版本)。
不过理论约定与实际常常脱节，一旦P3的author在发布v1.2.0时没有识别出与v1.1.0的不兼容change，那么这种情况下，不兼容v1.1.0的P3版本会导致对P1包的构建失败！这就是采用go module机制的依赖包时最常见的“依赖地狱”问题。
可以看到，这个问题的根源还是在于go module的author。识别不兼容的change难吗？也不难，但的确繁琐，费脑子。那么作为module author, 如何尽量避免未按照语义版本规范发布版本号兼容实则不兼容的module版本呢？
Go社区的作法分为两类：
- 极端作法：
- 不发布1.0版本，一直在0.x.y，不承诺新版本兼容老版本；
- 每次发稍大一些的版本都升级major版本号，这样既避免了繁琐的检查是否有不兼容change的问题，也肯定不会给社区带去“依赖地狱”问题。
- 常规作法：
- 检查是否有不兼容change，只有在存在不兼容change的情况下，才升级major版本。
Go官博曾经发表过一篇名为《Keeping Your Modules Compatible》的文章，以告诉大家如何检查新的change中是否有不兼容的change。文中还提到Go团队已经开发了一个名为gorelease的工具来帮助Go开发者检测新版本与旧版本之间是否存在不兼容的变化(当然，工具也很可能不能完全扫描出来不兼容性change)，大家可以在这里查看gorelease的详细用法。
4. 未来畅想
近几年成长时候也很迅猛的Rust语言在面对“依赖地狱”这一问题上似乎走到了Go的前面，在《How Rust Solved Dependency Hell》一文中大致讲解了Rust解决这一问题的方案。其原理大致是利用的名字修饰，即同一个依赖的两个不兼容的版本可以共存与一个Rust应用中，每个版本中的标识符在应用中都是独一无二的，Rust通过包名、版本号等作为名字修饰以达到此目的。
那么，未来Go modul能否做到这点呢？笔者认为是可行的，并且是兼容于现在go module的机制的。Go module的引入，实则也是一种“namespace”的概念，具备像Rust那样解决问题的基础。但Go团队是否要这么做就是另当别论了，因为一旦Go语言世界像本文开篇中所提到的那样，那么现有机制也可以很好地解决“依赖地狱”问题。
讲师主页：tonybai_cn
讲师博客: Tony Bai
专栏：《改善Go语言编程质量的50个有效实践》
实战课：《Kubernetes实战：高可用集群搭建,配置,运维与应用》
免费课：《Kubernetes基础：开启云原生之门》
随时随地看视频
