Golang语言中的Go Mod的版本和伪版本详解

前言

今天讲一下 Go Module 中软件包的版本和伪版本的内容，因为这是一个理想很丰满、现实很骨感的故事。

Module 的版本

关于 Go Module 依赖包的软件版本，这块知识就很中规中矩啦，大部分资料里也都有提及。

Go Modules模块的版本格式为“主版本号.次版本号.修订号”，版本号的递增规则如下：

v1.26.0
 | |  |_ _  修订号
 | | 
 | |_ _ _ _ 次版本号
 |
 |_ _ _ _ _ 主版本号

1. 主版本号：当你做了不兼容的更新时变更主版本号。
2. 次版本号：当你做了向下兼容的功能性更新时更改次版本号。
3. 修订号： 当你做了向下兼容的问题补丁修正时更改修订号。

不过当你在真正在项目里使用 Go Module 管理项目依赖的时候，尤其是你们公司内部的私有依赖模式时，你就会发现事情完全没有这么简单。

多数情况下，go.mod 文件里会有一堆依赖他们的版本会是酱婶儿的：

golang.org/x/lint v0.0.0-20200302205851-738671d3881b 
...
code.xxx.com/libs/xyz v1.0.10-0.20220805095508-6c1f3628ef7a

这个就是我们接下来要说的伪版本了。

Module 的伪版本

为什么mod 文件里有这么多伪版本 (pseudo-version) 呢，这里先跟大家插播一个小知识，大家在看技术文档的时候经常会有伪类，伪代码，伪版本这样的术语，他们基本上都是在原来的词根上加一个Pseudo 前缀，代表他们不是正式的类、代码、版本？（伪类好像不是那么回事，前端知识已经忘光了，😭），还有那个单词开头的P不发音… 不过好像咱们平时交流的时候念错了也没事，毕竟不少程序员哥哥，都把 alter 念成了alert，也不影响我们改MySQL的表。

Go Module 生成的伪版本主要有两种，其一是这种v0.0.0开头的：

golang.org/x/lint v0.0.0-20200302205851-738671d3881b

这种是因为依赖模块的代码仓库上不存在任何标签，所以go get 默认拉取的是主干分支最新一次commit对应版本的代码，并且在go.mod文件里为模块分配格式为 v0.0.0-主干分支最新一次commit的时间-commit哈希 这样的一个虚拟版本。

第二种是这种非  v0.0.0  开头的伪版本，比如：

code.xxx.com/libs/xyz v1.0.10-0.20220805095508-6c1f3628ef7a

这种一般是作为依赖包的项目本身代码仓库里有打标签发布版本，可是后续我们需要更新包，在测试阶段的时候在项目使用go get 模块名@CommitHash 获取还未正式发布的内容：

go get code.xxx.com/libs/xyz@6c1f3628ef7a

这个时候 Go Module 就会给我们在依赖已发布的版本上进行累加，然后生成伪版本，比如上面那个例子，模块的伪版本以v1.0.10开头就代表模块上一次发布的版本是v1.0.9，你打开模块所在的代码仓库看一下，一定会有一个v1.0.9的标签在那。

这里再放一个伪版本各部分的说明图给大家，方便理解记忆。

关于模块的伪版本，虽然我们掌握了它的生成规则，但使用的时候一定不要自己在 go.mod 文件里去编辑，而是使用上面举例的go get 命令，让 Go Module 自己生成模块的伪版本。

伪版本的乱象

针对在测试、开发阶段的依赖模块，因为不能在主干分支上打标签，我看到网上不少资料推荐以这种方式设置版本：

// 在测试分支上打标签
v1.2.30-test
// 在仿真分支上打标签
v1.2.30-pre

等模块测试通过，就可以在软件包的master分支打出v1.2.30标签，将引用模块的项目中go.mod文件里的依赖声明，更改成正式版本即可。

不过实际我看下来，更多的是使用伪版本的居多，而且很多线上项目在 go.mod 文件里直接就是引用的这些伪版本的模块。

这些问题咋一看起来没有什么事儿，但是我前段时间改了个被降本提效的团队的项目，里面就很多这种使用依赖的伪版本，更坑的是他们没把这个版本里的代码合并到主干，导致我更新了一个新版本，测试的时候，报了一个类似这样的错。

package provided […] but not at required version

Go Module 告诉我某个包在原来的版本的模块里，不在你声明的版本里… 。

总结

今天给大家介绍了 Go Module 关于模块版本管理的几个小知识，也说了下在开发模块时的一些乱象，咱们最好还是遵守上面说的，测试阶段在测试分支打标签，发布的时候一定要和到主干上打正式标签，项目不要还依赖着模块的伪版本呢就上线了，发布前检查一下 go.mod 及时更改过来，就不会像我这大冤种，天天给前人填坑啦。

互联网公司风风火火，人来的快走的也快，这些都是团队没有好的规范造成的，打工人也只能接受，但是我们一定要了解一些东西到底怎么用才是正确，怎么建立起良好的规范，才不会出现这种多人协作时一团乱的问题。

关于 Go 开发项目，实战方面更多的内容，我理了一本《Go 开发参考书》 收集了80多条开发实践。去公众号「网管叨bi叨」回复【gocookbook】即刻领取

这篇好文章是转载于：学新通技术网