Go mod 七宗罪

 mod 是 rsc 主导设计的 Go 版本管理工具，借鉴了 Google 内部的高大上版本管理方式，摒弃了开源社区的版本管理成功经验，借助 MVS 算法，希望能够走出一条不一样的路，然而从发布以来给广大 Gopher 带来了各种各样的麻烦。本文简单列举一部分罪状，Google 的并不一定总是世界的。

当然，随着 Go 1.16 的发布，其中有些罪证可能已经不成立了，读者可以自行甄别。

Go 命令的副作用

Go list，Go test，Go build，所有命令都会去拉取依赖，有些库是用被墙的服务做了重定向，只是执行一下 go test，然后就被卡一年是家常便饭。

按照 "By design" 的说法，Google 内部的依赖库版本都会尽量使用能够兼容的最新版本。对于墙内的我们来说，我不管执行什么 Go 命令怎么都卡。逐渐患上 go test PTSD。

解法：配置 GOPROXY 代理，虽然拉取依赖还是慢。

形同虚设的 semver 规范

社区里不遵守 semver 规范的库很多，有的开源库在 1.7.4 ~ 1.7.5 中进行了 breaking change，而按照 semver 的定义，这是不应该发生的。go mod 过度高估了开源社区的节操。

一开始，我们以为这只是社区的节操问题，直到我们碰到了 gRPC。

好样的哦，Google 工程师。

无法应对删库

leftpad 悲剧重演

js 社区使用集中式的 npm 来管理依赖，在几年前发生过一次因为作者删库，导致几乎所有互联网巨头的前端项目全部 build 失败的悲剧。同时 js 社区也进行了一些反思 how one programmer broke the internet[1]，have we forgotten how to program[2]。

npm 好歹还是集中式的版本管理方式，Go 号称分布式，但大多 Go 的依赖库都是存在 Github 上，如果 Github 上的原作者删除了该库，那么也会导致大多数的依赖用户 build 失败。

即使看起来我们可以靠 go.mod 和 go.sum 来实现 reproducible build，实际的情况是，像 k8s 这样的项目，依然会把庞大的依赖库放在自己 repo 的 vendor 里。

在笔者从 dd 离职时，也曾经不小心删除过一个认为应该没有人再依赖的个人库，当时给前同事们也造成了一些麻烦。

Github release/tag 水土不服

在 Github 上发布 lib 的 release，或者给某个 commit

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!