关于 Go 项目的依赖管理的日常使用以及遇到的问题怎么解决，俺已经写过两篇文章了。
- 项目使用GoModules管理依赖的方法和经验总结
- Go Modules怎么管理私有依赖
今天再跟大家唠一下 Go Module 中软件包的版本和伪版本的内容，因为这是一个理想很丰满、现实很骨感的故事。
Module 的版本
关于 Go Module 依赖包的软件版本，这块知识就很中规中矩啦，大部分资料里也都有提及。
Go Modules模块的版本格式为“主版本号.次版本号.修订号”，版本号的递增规则如下：
代码语言：javascript复制v1.26.0
| | |_ _ 修订号
| |
| |_ _ _ _ 次版本号
|
|_ _ _ _ _ 主版本号
- 主版本号：当你做了不兼容的更新时变更主版本号。
- 次版本号：当你做了向下兼容的功能性更新时更改次版本号。
- 修订号：当你做了向下兼容的问题补丁修正时更改修订号。
不过当你在真正在项目里使用 Go Module 管理项目依赖的时候，尤其是你们公司内部的私有依赖模式时，你就会发现事情完全没有这么简单。
多数情况下，go.mod 文件里会有一堆依赖他们的版本会是酱婶儿的：
代码语言：javascript复制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前缀，代表他们不是正式的类、代码、版本？（伪类好像不是那么回事，前端知识已经忘光了，
