dubbo-go v3 版本 go module 踩坑记( 三 )

pseudo-version 是 v1.4.2 ，这正是因为 go 认为 replace 后的 dubbogo 依赖主版本是 v1 ，去查找了该主版本下的最新 tag ，并递增了 patch version ，从而导致前后主版本不一致，当我们对版本路径加上 v3 后， go 查找不到对应主版本下的 tag ，为我们自动生成了 v3.0.0 ，从而通过了 CI。和 Java 不同， go 其实是没有子模块概念的。即使有些时候，我们会看到有个 repo 里有多个 Go modules ，比如项目的根目录有一个 go.mod，里面有些子目录里又有 go.mod。这在 Go modules 被称为嵌套模块，而非父子模块，即两个模块没有任何关系，是相互独立的。那什么时候才需要单 repo 多模块呢？一般来说，碰到以下两种情况我们才会考虑使用单 repo 多模块的开发形式。

某个嵌套模块变动非常频繁，需要经常发版。
当中的嵌套模块仅仅依赖某个固定版本的根模块。

两种情况其实本质都是两个模块之间没什么强的版本绑定关系，但是由于一些其他原因需要放在一个 rpeo 下，因此形成了单 repo 多模块的局面。 dubbo-go 使用了静态文件映射的方式实现了模块重定向，静态文件的内容如下：其中的核心部分是 meta 标签 go-import 和。

go-import 的作用，是告诉 go get 去哪儿可以找到源码， content 分为三部分：

dubbo.apache.org/dubbo-go/v3：这个项目的 module 声明。
git：使用的版本控制工具。
<https://github.com/apache/dubbo-go>：告诉 go get 这个项目应该去哪儿找源代码。

go-source 的作用，则是给项目生成具体的 go doc（现为 pkg.go.dev ) 文档，一共有 4 部分，前两部分和 go-import 一样，是该项目的 module 声明和版本控制工具，后两部分则分别起如下作用：

<https://github.com/apache/dubbo-go/tree/3.0{/dir}>：声明该项目的源代码所在位置。
<https://github.com/apache/dubbo-go/blob/3.0{/dir}/{file}#L{line}>：映射文档和代码，帮助我们在点击文档的目录树时，可以跳转到对应的具体内容。

比如在

就会跳转到对应文件对应的文档。