以下是一次引入第三方库版本问题导致的go mod依赖下载问题。这里是因为k8s/kubeutil/client引入了k8s/client-go/informers，然后后者又引入了k8s.io/api/auditregistration/v1alpha1。在当前项目下的go.mod里引入了k8s.io/api@latest（注意没有指定具体版本），然后go mod就提示这个最新版本的api里没有包含k8s.io/api/auditregistration/v1alpha1包
个人分析，在项目中引入了第三方依赖库的v1alpha1不稳定版本源码；因为v1alpha1版本的源码是不确定的，在后期版本迭代中，其中的内容是会发生翻天覆地的变化，甚至会删除。所以我们不要在自己的线上项目中引入一些v1alpha1版本的第三方依赖库，如果要引入时需要指定该第三方依赖库的指定版本，不要使用@latest的方式引入
有时候我们会在go.mod文件中遇到如下几种依赖包引入情况：
- 有的依赖包路径带有v字眼
- 有的是v1.7.3标准版本号
- 有的是v0.0.0-xxxx的版本描述
- 还有的版本号后带有+incompatible字眼
由于module版本号引入规则，如果想引入的module版本是大于1的，就需在引入路径后加入v2/v3/v4…等，就像下面的redis版本号为v8.0.0一样，他的引入路径带有v8字眼。
当我们想引入git上某个commit ID的代码版本时，如果这个commit ID的代码没有可用的版本tag，那么此时就可以直接通过go get k8s.io/apimachinery@d7deff9来下载该commit ID下的代码，这里的d7deff9就是Git上的Commit ID，此时go.mod文件，就会自动在该依赖路径后添加v0.0.0-20190313205120-d7deff9243b1版本字眼。
如果引入module版本大于1，我们不想在引入路径后加入v2/v3/v4…等字眼，我们就可以在版本号后加上+incompatible字眼，就像下面client-go的版本号为v11.0.0+incompatible；此处使用和上述带v2/v3/v4…等字眼的引入方式的使用是一样的。
module xxx/xxx go 1.14 require ( github.com/go-redis/redis/v8 v8.0.0-beta.6 github.com/gorilla/mux v1.7.4 k8s.io/apimachinery v0.0.0-20190313205120-d7deff9243b1 k8s.io/client-go v11.0.0+incompatible )参考
- incompatible解释和module版本号的遵循规则，https://my.oschina.net/renhc/blog/3167195
- https://blog.csdn.net/zhuiyunzhugang/article/details/109357168
- https://github.com/golang/go/wiki/Modules
- https://golang.org/cmd/go/#hdr-Pseudo_versions
- https://blog.csdn.net/gs80140/article/details/95320215
