先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
如果你需要这些资料，可以添加V获取：vip1024b （备注go）
正文
修改前：
go mod edit -replace=dubbo.apache.org/dubbo-go/v3=github.com/{PR_ORIGIN_REPO}@${PR_ORIGIN_COMMITID}
⇒ 修改后：
go mod edit -replace=dubbo.apache.org/dubbo-go/v3=github.com/${PR_ORIGIN_REPO}/v3@${PR_ORIGIN_COMMITID}
修复该问题后我们提交代码查看 CI，在 STEP 8 打印的日志信息中，可以看到替换后的 dubbogo 路径多了 v3，并且在拉包的时候跟的版本号（v3.0.0-20210509140455-2574eab5ad0b）主版本同样是 v3，成功拉取了依赖。
=========================================================================
在我们使用 Go modules 去构建项目的依赖关系时，对 go 项目的依赖都需要声明我们所使用的版本号，考虑到每次发布新版本时，兼容一直是开发者最为重视和头痛的问题，因此 go 通过**语义导入版本控制（Semantic Import Versioning）**来制定版本号的标准，来确保每个开发者能够根据自己的项目需求指定使用的依赖版本。根据 go 的语义导入版本控制准则，版本号由三部分构成：
注：上图及以上部分内容参考自《Go Modules 详解》一文。
其中 Major version 表示这是一个新的大版本，甚至这个新版本可能和旧版本是不兼容的。
而 Minor version 则表示这是一个大版本中的迭代，主要用于新增 feature 时递增。
Patch version 则是粒度最细的版本更新，表示一些 bug 的修复。
而指定主版本则有两种方式，一种是如上的直接声明，另一种则是在项目路径的最后加上版本后缀，如 dubbogo 3.0 版本声明的 module 则是 dubbo.apache.org/dubbo-go/v3，其中 v3 就是一个主版本的声明。
Go 在使用依赖时推崇我们指定明确的版本号，比如 dubbogo 的 go.mod 中声明的对 cloud.google.com/go 的依赖：
但考虑到在某些场景下，我们想要使用模块依赖的某个未发版的版本（该模块只有一个已知的 commit id），如 dubbogo 声明的 github.com/Microsoft/go-winio 依赖，就可以使用一个假定版本号（pseudo-version）去替代真实的版本号。假定版本号的格式为：
// (1) vX.0.0-yyyymmddhhmmss-abcdef123456
// (2) vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdef123456
// (3) vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdef123456+incompatible
// (4) vX.Y.Z-pre.0.yyyymmddhhmmss-abcdef123456
// (5) vX.Y.Z-pre.0.yyyymmddhhmmss-abcdef123456+incompatible
可以看到 pseudo-version 被短斜杠分为三部分，其中第一部分 X.Y.Z 与 4.1 节提到的一致，分别是 major version、minor version、patch version，而第二部分是一个格式为 yyyymmddhhmmss 的时间戳，第三部分是一个 12 位的 commit hash，可以手动指定，如果没有，则由 go 自动生成。
关于 pseudo-version，go 的生成规则如下：
-
查询该项目对应主版本（若项目依赖路径没有显式的 v2/v3 后缀，则默认为 v1 版本）的最新 tag。
-
有 tag 则使用最新 tag 递增 patch version。
-
无 tag ，根据项目路径带的后缀版本号自动生成（如 v3 则自动生成一个 3.0.0 开头的
pseudo-version）。
遵循这个规则，回头看前文的问题分析和问题解决，我们就可以明白为什么在一开始 dubbo-go 的 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-source。
Redirecting to pkg.go.dev/dubbo.apache.org/dubbo-go/v3...
1）go-import
go-import 的作用，是告诉 go get 去哪儿可以找到源码，content 分为三部分：
-
dubbo.apache.org/dubbo-go/v3：这个项目的 module 声明。 -
git：使用的版本控制工具。 -
<https://github.com/apache/dubbo-go>：告诉 go get 这个项目应该去哪儿找源代码。
2）go-source
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}>：映射文档和代码，帮助我们在点击文档的目录树时，可以跳转到对应的具体内容。
比如在 https://pkg.go.dev/dubbo.apache.org/dubbo-go/v3 上，我们点击其中一个文件：
就会跳转到对应文件对应的文档。
欢迎对 apache/dubbo-go 项目有兴趣的同学搜索钉钉群号 31363295，加入钉钉交流群！
- 《The Go Blog — Using Go Modules》：https://blog.golang.org/using-go-modules
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
o Modules》：https://blog.golang.org/using-go-modules
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）
[外链图片转存中…(img-SX6TWigQ-1713299210272)]
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
10万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
