标签 go.mod 下的文章

Go 1.17新特性详解：module依赖图修剪与延迟module加载

本文永久链接 – https://tonybai.com/2021/08/19/go-module-changes-in-go-1-17

Go module的引入终于让Go语言有了自己的包依赖管理标准机制与工具，虽说它的引入与推广过程略显坎坷，但不得不承认Go 1.11及之后的每一次Go版本发布，Go module都在进步！在Go 1.17版本中亦是如此，本篇我们就来详细聊聊在Go 1.17版本中Go module都有哪些重要的变化。

1. module依赖图修剪

本文的标题暗示了Go 1.17中go module的两个主要变化。module依赖图修剪(module graph pruning)是延迟module加载(lazy module loading)的基础。

我们以下图中的例子来解释一下什么是module graph pruning。

注：上图中的例子来自于Go 1.17源码中的src/cmd/go/testdata/script/mod_lazy_new_import.txt，通过执行txtar工具，我们可以将该txt转换为mod_lazy_new_import.txt中所描述的示例结构，转换命令为: txtar -x < \$GOROOT/src/cmd/go/testdata/script/mod_lazy_new_import.txt 。

在上面这个示例中，main module中的lazy.go导入了module a的package x，后者则导入了module b；并且module a还有一个package y，该包导入了module c。通过go mod graph命令我们可以得到main module的module graph，如图右上。

现在问题来了！package y是因为自身是module a的一部分而被main module所依赖，它没有为main module的构建做出任何“代码级贡献”；同理，package y所依赖的module c亦是如此。但是在Go 1.17之前的版本中，如果Go编译器找不到module c，那么main module的构建将会失败，这会让开发者们觉得不够合理！

我们回到上图对应的示例。在Go 1.16.5下，我们看看该示例的go.mod如下：

// github.com/bigwhite/experiments/tree/master/go1.17-examples/module/demo1/go.mod
module example.com/lazy

go 1.15

require example.com/a v0.1.0

replace (
    example.com/a v0.1.0 => ./a
    example.com/b v0.1.0 => ./b
    example.com/c v0.1.0 => ./c1
    example.com/c v0.2.0 => ./c2
)

我们只需关注require块中的内容，下面的replace块儿主要是为了示例能找到各种依赖module而设置的。我们知道在Go 1.16及以前支持Go module的版本所建立的go module中，其中的go.mod在go mod tidy后，require块儿中保留的都是main module的直接依赖(direct dependency)（在某些情况下，也会记录indirect依赖，这些依赖会在行尾用indirect指示符明示），因此在这里我们看不到main module的间接依赖以及它们的版本，我们可以用go mod graph来查看module依赖图，如下面命令及输出：

$go mod graph
example.com/lazy example.com/a@v0.1.0
example.com/a@v0.1.0 example.com/b@v0.1.0
example.com/a@v0.1.0 example.com/c@v0.1.0

这个go mod graph的输出与我们在上面图中右上角所画的module graph是一致的。此时，如果我们将replace中的第三行删除(example.com/c v0.1.0 => ./c1这一行)，即让Go编译器找不到module c@v0.1.0，那么我们构建main modue时将得到下面的错误提示：

$go build
go: example.com/a@v0.1.0 requires
    example.com/c@v0.1.0: missing go.sum entry; to add it:
    go mod download example.com/c

现在我们将执行权限交给Go 1.17！我们需要对go.mod做一些修改（将go.mod中的go 1.15改为go 1.17），这样Go 1.17才能起到作用。接下来，我们执行go mod tidy，让Go 1.17重新构建go.mod：

$go mod tidy
$cat go.mod

module example.com/lazy

go 1.17

require example.com/a v0.1.0

require example.com/b v0.1.0 // indirect

replace (
    example.com/a v0.1.0 => ./a
    example.com/b v0.1.0 => ./b
    example.com/c v0.1.0 => ./c1
    example.com/c v0.2.0 => ./c2
)

我们看到执行go mod tidy之后，go.mod发生了变化：增加了一个require语句块，记录了main module的间接依赖：module b@v0.10。

现在，我们也同样将go.mod replace块中的第三行删除(example.com/c v0.1.0 => ./c1这一行)，我们再来用go 1.17构建一次main module，这一次我们没有看到Go编译器的错误提示。也就是说在构建过程中，Go编译器所看到的main module依赖图中并没有module c@v0.1.0。由于module c并没有为main module的构建提供“代码级贡献”，Go命令将其从module依赖图中剪除，Go编译器使用的真实的依赖图如上图右下角所示(pruned module graph)。

这种将那些“占着茅坑不拉屎”、对构建完全没有“贡献”的间接依赖module从构建时使用的依赖图中修剪掉的过程，就被称为module依赖图修剪。

之所以要这么做，就是因为Go社区反馈了较多的这方面的问题。这么做的好处是显而易见的：我们再也不用为那些没有对构建没有做出任何“代码级贡献”但又容易出现各种“问题”的module的埋单了。

但module依赖图修剪也带来了一个副作用，那就是go.mod文件size的变大。因为Go 1.17版本后，每次go mod tidy，go命令都会对main module的依赖做一次深度扫描(deepening scan)，并将main module的所有直接和间接依赖都记录在go.mod中。考虑到内容较多，go 1.17将直接依赖和间接依赖分别放在两个不同的require块儿中。

我们以gnet为例，Go 1.17版本之前的go.mod如下：

module github.com/panjf2000/gnet

go 1.16

require (
    github.com/BurntSushi/toml v0.3.1 // indirect
    github.com/panjf2000/ants/v2 v2.4.6
    github.com/stretchr/testify v1.7.0
    github.com/valyala/bytebufferpool v1.0.0
    go.uber.org/atomic v1.8.0 // indirect
    go.uber.org/multierr v1.7.0 // indirect
    go.uber.org/zap v1.18.1
    golang.org/x/sys v0.0.0-20210630005230-0f9fa26af87c
    gopkg.in/natefinch/lumberjack.v2 v2.0.0
)

// Go module checksum mismatch, see https://github.com/panjf2000/gnet/issues/219
// retract v1.4.5

使用Go 1.17重新mod tidy后，go.mod内容如下：

module github.com/panjf2000/gnet

go 1.17

require (
    github.com/BurntSushi/toml v0.3.1 // indirect
    github.com/panjf2000/ants/v2 v2.4.6
    github.com/stretchr/testify v1.7.0
    github.com/valyala/bytebufferpool v1.0.0
    go.uber.org/atomic v1.8.0 // indirect
    go.uber.org/multierr v1.7.0 // indirect
    go.uber.org/zap v1.18.1
    golang.org/x/sys v0.0.0-20210630005230-0f9fa26af87c
    gopkg.in/natefinch/lumberjack.v2 v2.0.0
)

require (
    github.com/davecgh/go-spew v1.1.1 // indirect
    github.com/pmezard/go-difflib v1.0.0 // indirect
    gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b // indirect
)

我们看到go 1.17后，go.mod中的main module的依赖分成了两个require块儿，第一个是直接依赖，第二个是间接依赖。但我们看到第一个require中也有包含indirect指示符的依赖。Go关于indirect指示符的使用总是很让人迷惑。关于究竟在Go 1.17中的require中如何使用indirect指示符，可以在这个讨论中找到一些线索。

Go 1.17后go.mod中存储了main module的所有依赖module列表，这似乎也是Go项目第一次有了项目依赖的完整列表，这是不是让你想起了其他主流语言构架系统中的那个lock文件。虽然go.mod不是lock文件，但有了完整依赖列表，至少我们可以像其他语言的lock文件那样，知晓当前Go项目所有依赖的精确版本了。

2. 延迟module加载(lazy module loading)

有了module依赖图修剪作为铺垫，延迟module加载就相对好理解了。其含义就是那些在完整的module graph(complete module graph)中，但不在pruned module graph中的module的go.mod不会被go命令加载。

3. module deprecation注释

在Go 1.16版本在go.mod中加入retract以支持作废某个module的特定版本后，go 1.17更进一步地在go.mod中增加了Deprecated注释，以帮助go module作者作废自己的module。go module作者只需在自己的go.mod中的module声明上面用// Deprecated: comment对module做出注释，就像下面这样：

// Deprecated: use example.com/mod/v2 instead.
module example.com/mod

对于那些使用了被废弃的module的go项目，go list、go get命令都会给出warning。

注意和retract不同，我们不能用Deprecated去作废minor或patch版本，Deprecated是用来作废整个module的。但不同major版本的module被视为不同的module。因此，go module作者一般像上面例子中那样，在Deprecated注释中提示升级到更新的版本，比如：v2版本。

4. 其他一些改变

  • 如果一个main module的go.mod中没有go版本指示符，go 1.17版本的go命令会将其默认为go 1.11版本;
  • 如果一个module的依赖module没有go.mod或该依赖module的go.mod中没有go指示符，go 1.17版本的go命令会将其go.mod中的版本指示符默认为go 1.16，而不是go命令的版本；
  • 如果main module的go.mod中go版本指示符的值为go 1.17及以上版本，那么go mod vendor会在vendor/modules.txt中记录被vendor的module使用的go version，见下面对比：

main module的go.mod中go version < 1.17：

# github.com/BurntSushi/toml v0.3.1
## explicit
# github.com/davecgh/go-spew v1.1.1
github.com/davecgh/go-spew/spew
# github.com/panjf2000/ants/v2 v2.4.6
## explicit
github.com/panjf2000/ants/v2
github.com/panjf2000/ants/v2/internal
# github.com/pmezard/go-difflib v1.0.0
github.com/pmezard/go-difflib/difflib
# github.com/stretchr/testify v1.7.0
## explicit
github.com/stretchr/testify/assert
github.com/stretchr/testify/require
# github.com/valyala/bytebufferpool v1.0.0
## explicit
github.com/valyala/bytebufferpool
... ...

main module的go.mod中go version >= 1.17：

// vendor/modules.txt

# github.com/BurntSushi/toml v0.3.1
## explicit
# github.com/davecgh/go-spew v1.1.1
## explicit
github.com/davecgh/go-spew/spew
# github.com/panjf2000/ants/v2 v2.4.6
## explicit; go 1.14
github.com/panjf2000/ants/v2
github.com/panjf2000/ants/v2/internal
# github.com/pmezard/go-difflib v1.0.0
## explicit
github.com/pmezard/go-difflib/difflib
# github.com/stretchr/testify v1.7.0
## explicit; go 1.13
github.com/stretchr/testify/assert
github.com/stretchr/testify/require
# github.com/valyala/bytebufferpool v1.0.0
... ...
  • 如果main module go.mod中go version指示版本>= go 1.17，那么go mod vendor将忽略各个依赖包中的go.mod和go.sum，这两个文件将不会出现在vendor目录下的各个被vendor的module目录中。

5. 小结

Go 1.17通过对构建时使用的module graph的修剪，让我们再也不用为那些对项目没有代码级贡献但又极容易给构建过程带来麻烦的依赖所烦恼了。新版go.mod的格式还让我们拥有了一份完整的项目依赖列表，这种直观让开发者有一种安全和踏实的感觉。

本文涉及的所有代码可以从这里下载：https://github.com/bigwhite/experiments/tree/master/go1.17-examples

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强。在2021年上半年，部落将策划两个专题系列分享，并且是部落独享哦：

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎大家加入！

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中！本专栏主要满足广大gopher关于Go语言进阶的需求，围绕如何写出地道且高质量Go代码给出50条有效实践建议，上线后收到一致好评！欢迎大家订
阅！

img{512x368}

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网热卖中，欢迎小伙伴们订阅学习！

img{512x368}

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

  • 微博：https://weibo.com/bigwhite20xx
  • 微信公众号：iamtonybai
  • 博客：tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go 1.17中值得关注的几个变化

本文永久链接 – https://tonybai.com/2021/08/17/some-changes-in-go-1-17

Go核心开发团队在去年GopherCon大会上给Go泛型的定调是在2022年2月份的Go 1.18版本中发布，那可是自Go诞生以来语法规范变动最大的一次，这让包括笔者在内的全世界的Gopher们都满怀期待。

不过别忘了，在Go 1.18这个“网红版本”发布前，还有一个“实力派”版本Go 1.17呢！美国当地时间2021年8月16日，Go 1.17版本在经过两个RC版本之后正式发布！并且值得庆幸的是Go 1.17版本并没有过多受到Go 1.18版本这个“网红”的影响，Go 1.17默默地加入和优化了着实不少的特性。在这一篇文章中，我们就来看看Go 1.17版本中有哪些值得关注的变化。

1. 语言特性变化

Go属于那种极简的语言，从诞生到现在语言自身特性变化很小，不会像其他主流语言那样走“你有的我也要有”的特性融合路线。因此新语言特性对于Gopher来说属于“稀缺品”，属于“供不应求”那类事物^_^。这也直接导致了每次Go新版本发布，我们都要首先看看语言特性是否有变更，每个新加入语言的特性都值得我们去投入更多关注，去深入研究。Go 1.17在语言特性层面做了两方面的小改动，下面我们来看看。

第一个是对语言类型转换规则的扩展，允许从切片到数组指针的转换，下面的代码在Go 1.17版本中是可以正常编译和运行的：

// github.com/bigwhite/experiments/tree/master/go1.17-examples/lang/slice2arrayptr/main.go
func slice2arrayptr() {
    var b = []int{11, 12, 13}
    var p = (*[3]int)(b)
    p[1] = p[1] + 10
    fmt.Printf("%v\n", b) // [11 22 13]
}

Go通过运行时对这类切片到数组指针的转换代码做检查，如果发现越界行为，就会通过运行时panic予以处理。Go运行时实施检查的一条原则就是“转换后的数组长度不能大于原切片的长度”，注意这里是切片的长度(len)，而不是切片的容量(cap)。

第二个变动则是unsafe包增加了两个函数：Add与Slice。使用这两个函数可以让开发人员更容易地写出符合unsafe包使用的安全规则的代码。这两个函数原型如下：

// $GOROOT/src/unsafe.go
func Add(ptr Pointer, len IntegerType) Pointe
func Slice(ptr *ArbitraryType, len IntegerType) []ArbitraryType

unsafe.Add允许更安全的指针运算，而unsafe.Slice允许更安全地将底层存储的指针转换为切片。

2. go module的变化

自Go 1.11版本引入go module以来，每个Go大版本发布时，go module都会有不少的积极变化，这是Go核心团队与社区就go module深入互动的结果。

Go 1.17中go module同样有几处显著变化，其中最最重要的一个变化就是pruned module graph（修剪的module依赖图）。Go 1.17之前的版本某个module的依赖图由该module的直接依赖以及所有间接依赖组成，无论某个间接依赖是否真正为原module的构建做出贡献，这样go命令在解决依赖时会读取每个依赖的go.mod，包括那些没有被真正使用到的module，这样形成的module依赖图被称为完整module依赖图（complete module graph）。

Go 1.17不再使用“完整module依赖图”，而是引入了pruned module graph（修剪的module依赖图）。修剪的module依赖图就是在完整module依赖图的基础上将那些“占着茅坑不拉屎”、对构建完全没有“贡献”的间接依赖module修剪后的依赖图。使用修剪后的module依赖图进行构建将有助于避免下载或阅读那些不必要的go.mod文件，这样Go命令可以不去获取那些不相关的依赖关系，从而在日常开发中节省时间。

但module依赖图修剪也带来了一个副作用，那就是go.mod文件size的变大。因为Go 1.17版本后，每次go mod tidy（当go.mod中的go版本为1.17时），go命令都会对main module的依赖做一次深度扫描(deepening scan)，并将main module的所有直接和间接依赖都记录在go.mod中（之前说的版本只记录直接依赖）。考虑到内容较多，go 1.17将直接依赖和间接依赖分别放在两个不同的require块儿中。

3. 编译器与运行时的变化

Go 1.17增加了对Windows上64位ARM架构的支持，让开发者可以在更多设备上原生运行Go。但这个版本编译器最大的变化是在amd64架构下率先实现了从基于堆栈的调用惯例到基于寄存器的调用惯例的切换。

并且，切换到基于寄存器的调用惯例后，一组有代表性的Go包和程序的基准测试显示，Go程序的运行性能提高了约5%，二进制文件大小典型减少约2%。也就是说你的Go源码使用Go 1.17版本重新编译一下就能获得大约5%的性能提升，真希望这样的优化越多越好！对更多平台的基于寄存器调用惯例的支持将在未来的版本中出现。

除了改为基于寄存器的调用惯例之外，Go 1.17编译器还支持包含闭包的函数的内联(inline)了！这样一来，一个带有闭包的函数可能会在函数被内联的每个地方产生一个不同的闭包代码指针，因此，
Go函数的值不能直接比较！

Go编译器还在Go 1.17中引入了//go:build形式的构建约束指示符，以替代原先易错的// +build形式。

4. 其他变化

  • 保留龙芯架构GOARCH值

在Go 1.17版本中，Go编译器保留了中国龙芯cpu架构的GOARCH值 – loong64。关于龙心GOARCH值选用loong64还是loongarch64还有过一段激烈的争论，最终大多数都赞同的loong64取得了最后的胜利。

  • Go test变化

Go test引入-shuffle的洗牌标志位，用以控制单元测试或benchmark的执行顺序。

另外T和B两个类型分别都增加了Setenv方法用于在test和benchmark执行期间设置环境变量。

  • time包增加Time对象的GoString形式输出

我们使用%#v输出一个Time对象实例时，Go 1.17之前的版本输出内容如下面：

Go 1.16.5输出：

time.Time{wall:0xc03f08c0d06c9ed0, ext:83078, loc:(*time.Location)(0x11620e0)}

Go 1.17增加了GoString方法，该方法在Time对象以%#v格式输出时被自动调用，其输出结果如下：

time.Date(2021, time.August, 17, 20, 29, 42, 58245000, time.Local)

5. 小结

除上述变化之外，Go的其他标准库随着新版本的发布也都会有大量的小改动，但每个开发人员对标准库的关注点差别很大，因此，在这个系列中不会详细做说明了，大家还是参考Go 1.17的发布说明文档各取所需吧^_^。

与传统的“Go新版本值得关注的几个变化”系列有所不同，本期内容较为简单和概括，因为更多内容，我将在后续的Go 1.17新特性详解系列中针对上述值得关注的新特性做进一步说明。详解系列已经写好，不过首发在了本人运营的星球“Gopher部落”上了，如果你迫切想深入了解这些新特性，可以加入星球阅读。

本文所涉及的源码可以在这里 – https://github.com/bigwhite/experiments/tree/master/go1.17-examples/

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强。在2021年上半年，部落将策划两个专题系列分享，并且是部落独享哦：

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎大家加入！

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中！本专栏主要满足广大gopher关于Go语言进阶的需求，围绕如何写出地道且高质量Go代码给出50条有效实践建议，上线后收到一致好评！欢迎大家订
阅！

img{512x368}

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网热卖中，欢迎小伙伴们订阅学习！

img{512x368}

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

  • 微博：https://weibo.com/bigwhite20xx
  • 微信公众号：iamtonybai
  • 博客：tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

  1. « Previous
  2. ...
  3. 25
  4. 26
  5. 27
  6. 28
  7. 29
  8. 30
  9. 31
  10. 32
  11. 33
  12. 34
  13. 35
  14. ...
  15. Next »
如发现本站页面被黑，比如：挂载广告、挖矿等恶意代码，请朋友们及时联系我。十分感谢！ Go语言第一课 Go语言进阶课 AI原生开发工作流实战 从 0 开始构建 Agent Harness Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com
这里是 Tony Bai的个人Blog，欢迎访问、订阅和留言！ 订阅Feed请点击上面图片。

如果您觉得这里的文章对您有帮助，请扫描上方二维码进行捐赠 ，加油后的Tony Bai将会为您呈现更多精彩的文章，谢谢！

如果您希望通过微信捐赠，请用微信客户端扫描下方赞赏码：

如果您希望通过比特币或以太币捐赠，可以扫描下方二维码：

比特币：

以太币：

如果您喜欢通过微信浏览本站内容，可以扫描下方二维码，订阅本站官方微信订阅号“iamtonybai”；点击二维码，可直达本人官方微博主页^_^：
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机，即可获得10美元现金充值，可 免费使用两个月哟！ 著名主机提供商Linode 10$优惠码：linode10，在 这里注册即可免费获 得。阿里云推荐码： 1WFZ0V， 立享9折！


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

AI API Blog Blogger C Channel Cpp docker GC GCC github Go Golang Google Gopher goroutine Go语言 Interface Java k8s Kubernetes Linux Opensource Package Programmer Python RobPike runtime Rust Ubuntu Unix 博客 垃圾回收 容器 工作 开源 思考 感悟 接口 标准库 泛型 生活 程序员 编译器 软件工程

归档



View My Stats