标签 GOPATH 下的文章

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

本文永久链接 – https://tonybai.com/2024/02/18/some-changes-in-go-1-22

美国时间2024年2月6日,正当中国人民洋溢在即将迎来龙年春节的喜庆祥和的气氛中时,Eli Bendersky代表Go团队在Go官博发文“Go 1.22 is released!”,正式向世界宣告了Go 1.22版本的发布!

注:大家可以从Go官网下载Go 1.22的第一个版本go 1.22.0,也可以在Go playground上选择Go 1.22版本在线体验Go 1.22的语法。

记忆中,这似乎是Eli Bendersky首次代表Go团队撰写Go版本发布的文章,文章短小且言简意赅,会让大家误以为Go 1.22版本没有太多的功能点变更,其实不然。读过我之前写的“Go 1.22新特性前瞻”一文的童鞋都知道Go 1.22中有很多重要且影响深远的值得我们关注的变化。在这篇文章中,我们就再来介绍一下这些变化,供大家参考。

0. 插播“旧闻”:Go再次进入Top10,并刷新有史以来的最高排名

TIOBE编程语言排行榜发布2024年2月编程语言排名的时间恰逢中国人民的传统佳节春节期间,因此它的这次排名发布“淹没”在了“龙年大吉”的喜庆气氛当中了。年后开工,大家翻看这条“旧闻”时,才发现在这次排名中,Go再一次回到Top10,位列第8名,刷新了Go打榜一来的历史最好位次。

单看这一次进入top10似乎没有什么,因为2023年4月份,Go也跻身过top10,排名第10。但如果从Go打榜以来的历史曲线来看,如下图:

我们看到了“翘尾”,我们看到了Go迈过“低谷”后的爬升!这与我在《Go语言第一课专栏》的结课语《和你一起迎接Go的黄金十年》中预判:Go即将迎来自己的黄金十年 愈来愈吻合了!

不过,我在《2023年Go语言盘点:稳中求新,稳中求变》一文中提到过TIOBE index作为世界最知名的编程语言排行榜,却存在其“不靠谱”的特性,比如这一期排名中,上古时代的编程语言Fortran从去年同期的第24位上升至第11位,仅比PHP落后一位,另一门古老的COBOL语言也从去年同期的第30位上升至第19位,仅仅比大热的Rust语言落后一位。

因此,对于TIOBE的排名,大家既要了解,也无需过于看重^_^。

言归正传,我们来说说Go 1.22版本的变化。

1. 语言变化

Go 1.22对语言语法做了两处变更,一个是Go 1.21版本中的试验特性loopvar在Go 1.22中转正落地;另一个也和for循环有关,那就是for range新增了对整型表达式的支持。两者相比较,还是第一个变化loopvar带来的影响更大一些。为什么呢?因此这是Go语言发展历史上第一次真正的填语义层面的“坑”,而且修改的是一个在Go源码中最常用的控制结构的执行语义,这很大可能会带来break change。Go101教程的作者老貘将之成为Go历史上最大的向后兼容性破坏版本

注:Go 1.21版本有一个对panic(nil)的语义修正,但我估计很少会有人写出panic(nil)这样的代码。

这次语义修改用一句话表达就是:将经典三段式for循环语句以及for range语句中的用短声明形式定义的循环变量从整个循环定义和共享一个,变为每个迭代定义一个

这里借用Go官博文章中那个例子再说明一下这个语义变化:

// go1.22-examples/lang/loopvar/main.go
package main

import (
    "fmt"
    "time"
)

func main() {
    done := make(chan bool)

    values := []string{"a", "b", "c"}
    for _, v := range values {
        go func() {
            time.Sleep(time.Second)
            fmt.Println(v)
            done <- true
        }()
    }

    // wait for all goroutines to complete before exiting
    for _ = range values {
        <-done
    }
}

我们用Go 1.22.0版本之前的版本,比如Go 1.21.0,来运行该示例:

$go run main.go
c
c
c

我们看到:由于v是整个循环中各个迭代共享的一个变量,所以在每个迭代新创建的goroutine中输出的v都是循环结束后v的最终值c。

如果我们用go 1.22.0来运行上述示例,我们将得到:

// 输出的值的顺序与goroutine调度有关
$go run main.go
b
c
a

注:关于Go 1.22版本之前的for range的坑,我的极客时间专栏《Go语言第一课》专栏有图文并茂的原理讲解,欢迎订阅阅读。

那么,loopvar这一语义填“坑”究竟会对你的代码造成怎样的影响呢?在Russ Cox关于loopvar语义变更的设计文档中提到了:只有go.mod中的go version在go 1.22.0及以后的时候才会生效,这是一个渐进式过渡的过程,因此目前无论是开源项目还是商业项目,只要go.mod中的go version还没有更新为大于等于go 1.22.0,那么for循环依然会保留短声明定义的变量的原语义,这样这些项目都不会受到影响。

不过,如果是直接在脚本中通过go run xxx.go形式运行某个go源码的,且当前工作目录以及父目录下没有go.mod文件的,go 1.22.0会采用新的loopvar语义,这点大家要注意了。

此外,当你将go.mod中的go version升级到go 1.22.0或更高版本时,也要注意语义变更可能带来的问题。在升级go version之前,可以用Go 1.22版本之前的go vet对项目源码进行一次静态分析,对于go vet提示:“loop variable v captured by func literal”的地方务必注意逐个确认。

注:Go 1.22版本中的go vet已经移除了在go version >= 1.22.0时,对“loop variable v captured by func literal”情况进行警告的功能。

关于Go 1.22中for range支持后面接整型表达式的“语法糖”新特性以及函数迭代器的实验特性,这里就不细说了,大家可以看看“Go 1.22新特性前瞻”一文中的说明。

2. 编译器、运行时与工具链

在编译器、运行时和工具链这些方面,Go 1.22的正式版本与“Go 1.22新特性前瞻”一文中使用的Go 1.22rc1版本几乎没有差异,这里挑主要内容介绍一下,其他一些内容可以参考前瞻一文。

Go 1.22版本继续在编译上优化PGO(profile-guided optimization), 基于PGO的构建可以比以前版本实现更高比例的调用去虚拟化(devirtualize)。在Go 1.22中,官⽅给出的PGO带来的性能提升数字是2%~14%,这应该是基于Google内部一些典型的Go程序测算出来的。

注:如果你对PGO优化还不是很了解,可以看看“深入理解Profile Guided Optimization(PGO)”这篇文章。

Go 1.22版本编译器现在可以更多运⽤devirtualize和inline。在Go编译器中,devirtualize是一种编译优化技术,旨在消除“虚函数”调用的开销。“虚函数”是指在面向对象编程中,通过基类指针或引用调用的函数。在Go中所谓虚函数调用指的就是通过接口类型变量进行的方法调用。由于是动态调用,基于接口的方法调用需要在运行时进行查找和分派,这可能导致一定的性能损失。

而Go编译器在进行devirtualize优化时,会尝试根据程序的上下文信息和类型信息,确定方法调用的具体对象实例。如果编译器能够确定调用的具体实例,则会将通过接口的方法调用替换为直接调用具体对象实例的方法,从而消除运行时的开销,使得通过接口类型变量进行方法调用的性能得到优化提升。

Go 1.22版本中的运行时可以使基于类型的垃圾收集的元数据更接近每个堆对象,从而将Go程序的CPU性能(延迟或吞吐量)提高了1-3%。这一变化还支持通过重复数据删除冗余元数据,进而将大多数Go程序的内存开销减少了大约1%。

在工具链方面,有三个主要改变这里提一下:

  • go work支持vendor

在Go 1.22版本中,通过go work vendor可以将workspace中的依赖放到vendor⽬录下,同时在构建时,如果workspace下有vendor⽬录,那么默认的构建是go build -mod=vendor,即基于vendor的构建。

  • go mod init不再care其他vendor工具的配置文件

go mod init不再尝试将其他vendor工具(例如Gopkg.lock )的配置文件导入到go module依赖文件(go.mod)中了,也就是说从Go 1.22版本开始,go module出现之前的那些gopath时代的依赖管理工具正式退出并成为历史了。

  • 改进go test -cover的输出

对于没有自己的测试文件的包,go test -cover在go 1.22版本之前会输出:

? mymod/mypack [no test files]

但在Go 1.22版本之后,会报告覆盖率为0.0%:

mymod/mypack coverage: 0.0% of statements

3. 标准库

这里列举一下标准库值得关注的重大变化,大家可以与前瞻一文相互参考着阅读。

3.1 math/rand/v2:标准库的第一个v2版本包

Go 1.22中新增了math/rand/v2包,这里之所以将它列为Go 1.22版本标准库的⼀次重要变化,是因为这是标准库第一次为某个包建⽴v2版本,按照Russ Cox的说法,这次math/rand/v2包的创建,算是为标准库中的其他可能的v2包“探探路”,找找落地路径。关于math/rand/v2包相对于原math/rand包的变化有很多,具体可以参考issue 61716中的设计与讨论。

3.2 增强http.ServeMux表达能力

在Go 1.22版本中,http.ServeMux的表达能力得到了大幅提升,从原先只支持静态路由,到新版本中支持如下一些特性:

  • “/index.html”路由将匹配任何主机和方法的路径”/index.html”;
  • “GET /static/”将匹配路径以”/static/”开头的GET请求;
  • “example.com/”可以与任何指向主机为”example.com”的请求匹配;
  • “example.com/{$}”会匹配主机为”example.com”、路径为”/”的请求,即”example.com/”;
  • “/b/{bucket}/o/{objectname…}”匹配第一段为”b”、第三段为”o”的路径。名称”bucket”表示第二段,”objectname”表示路径的其余部分。

并且新版ServeMux在路由匹配性能方面也不输众多开源http路由框架太多,后续建立Go web或api类新项目时,可以考虑首选新版ServeMux来进行路由匹配了,减少对外部的一个依赖。

关于新版http.ServeMux的具体使用方法,其作者Jonathan Amsterdam(也是log/slog的作者)在官博发表了一篇名为“Routing Enhancements for Go 1.22”的文章,大家可以详细参考。

关于标准库的其他一些变化,大家可以参考前瞻一文以及更详细的Go 1.22的发布说明文档

4. 小结

综上,Go 1.22版本对语言、编译器、工具链、运行时和标准库都有一定程度的改进和创新,遗留代码通过Go 1.22版本的重新编译便可以得到一定程度的性能上的自然提升,这也体现了Go语言在稳中求新、稳中求变的特点。

不过这里还要提醒各位Go开发者,在升级Go 1.22版本时务必注意潜在的向后兼容性问题,尤其是loopvar语义带来的变化影响。

本文涉及的源码可以在这里下载。


Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时,我们也会加强代码质量和最佳实践的分享,包括如何编写简洁、可读、可测试的Go代码。此外,我们还会加强星友之间的交流和互动。欢迎大家踊跃提问,分享心得,讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落,享受coding的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

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

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

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

聊聊Go语言的向前兼容性和toolchain规则

本文永久链接 – https://tonybai.com/2023/09/10/understand-go-forward-compatibility-and-toolchain-rule

Go语言在发展演进过程中一直十分注重向后兼容性(backward compatibility),在Go 1.0版本发布之初就发布了Go1兼容性承诺,简单来说就是保证使用新版本Go(比如Go 1.21版本)可以正常编译和运行老版本的Go代码(比如使用Go 1.18版本语法编写的go代码),不会出现breaking change(其实也不是绝对的不会出现)。

但是在Go 1.21版本之前,Go语言在向前兼容性方面却存在一定的不确定性问题。Go 1.21版本对此进行了改进,并引入了go toolchain规则。本文就和大家详细聊聊Go语言的向前兼容性以及Go 1.21中新引入的toolchain的使用规则。

1. Go 1.21版本之前的向前兼容性问题

在Go 1.21版本之前,Go module中的go directive用于声明建议的Go版本,但并不强制实施。例如:

// go.mod
module demo1

go 1.20

上面go.mod文件中的go directive表示建议使用Go 1.20及以上版本编译本module代码,但并不强制禁止使用低于1.20版本的Go对module进行编译。你也可以使用Go 1.19版本,甚至是Go 1.15版本编译这个module的代码。

但Go官方对于这种使用低版本(比如L)编译器编译go directive为高版本(比如H)的Go module的结果没有作出任何承诺和保证,其结果也是不确定的

如果你比较幸运,在module中没有使用高版本(从L+1到H)引入go的新语法特性,那么编译是可以通过的。

如果你更加幸运,你module中的代码没有使用到任何从L+1到H版本中带有语法行为变更、bug或安全漏洞的代码,那么编译出的可执行程序运行起来也可以是正常的。

相反,你可能会遇到编译失败、运行失败甚至运行时行为出现breaking change的问题,而这些都是不确定的

有gopher可能会说:我自己的代码可以控制,我可以保证避免掉这些问题。但如果你的module有外部依赖,你能保证你的依赖不存在这种向前兼容性的问题吗!

向前兼容性问题会导致Go开发者的体验不佳!因此,从Go 1.21版本开始,Go团队在向前兼容性方面对Go进行了改善,尽量以确定性代替上述的问题带来的不确定性。

下面我们就来看看Go 1.21版本在向前兼容性方面的策略调整。

2. Go 1.21版本后的向前兼容性策略

Go从Go 1.11版本引入go module,在go 1.16版本go module构建模式正式成为默认构建模式,替代了原先的GOPATH构建模式。

注:《Go语言第一课》专栏的第6讲第7讲对Go module构建模式与6类常规操作做了全面系统的讲解,感兴趣的童鞋可移步阅读。

通过go module,结合语义导入版本(semantic import versioning)最小版本选择(Minimal version selection)等机制,go build可以实现精确的依赖管控。

Go 1.21版本后的向前兼容性策略的调整就是参考了go module对依赖的管理方法:即将go版本和go toolchain版本作为一个module的“依赖”来管理。如果你真正理解了这个,那理解后面那些具体的规则就容易多了!

如果Russ Cox当初设计Go module就想到了今天这个思路,估计就会直接使用go.mod文件中的require语法像管理依赖module那样来管理go version和go toolchain了:

// go.mod (假想的)

module demo1

require (
    go 1.20.5
    toolchain go1.21.1
)

require (
    github.com/gomodule/redigo v1.8.5
    github.com/google/gops v0.3.19
    github.com/panjf2000/ants v1.2.1
)

但时间无法倒流,历史不能重来,Russ Cox现在只能使用go directive和toolchain directive来提供对go版本和go工具链的依赖信息:

// go.mod

module demo1

go 1.20.5
toolchain 1.21.1

同时和使用go get可以改变go.mod的require块中的依赖的版本一样,通过go get也可以修改go.mod中go和toolchain指示的版本:

$go get go@1.21.1
$go get toolchain@go1.22.1

基于上述策略调整,为解决向前兼容不确定性的问题,Go从1.21版本开始,改变了go.mod中go directive的语义:它不再是建议,而是指定了module最小可用的Go版本。

这样在仅使用本地go工具链的情况下,如果Go编译器版本低于go.mod中的go版本,将无法编译代码:

// go.mod

module demo1

go 1.21.1 // 指定最小可用版本为Go 1.21.1

$GOTOOLCHAIN=local go build
go: go.mod requires go >= 1.21.1 (running go 1.21.0; GOTOOLCHAIN=local)

细心的读者可能会注意到了,这里我用了一个前提:“在仅使用本地go工具链的情况下(即设置了GOTOOLCHAIN=local)”,在Go 1.21版本之前,我们遇到的都属于这种情况。遇到这种情况后,我们一般的作法是手动下载对应版本的Go工具链(比如这里的go 1.21.1),然后用新版工具链重新编译。

Go团队考虑到手动管理go工具链带来的体验不佳问题,在Go 1.21版本及以后,go还提供了自动Go工具链管理,如果go发现本地工具链版本低于go module要求的最低go版本,那么go会自动下载高版本的go工具链,缓存到go module cache中(不会覆盖本地安装的go工具链),并用新下载的go工具链对module进行编译构建:

// go.mod

module demo1

go 1.21.1 // 指定最小可用版本为Go 1.21.1

$go build
go: downloading go1.21.1 (darwin/amd64)

注:从兼容性方面考虑,如果go.mod中没有显式的用go指示go版本,那么默认go版本为1.16。

对应module有依赖的情况,比如下图:

这里要正确编译图中的main module,我们至少需要go 1.21.0版本,这个版本是main所有依赖中version最大的那个。

当然最终选择哪个版本的go工具链对module进行编译,则有一个选择决策的过程。

go module构建模式下,go工具链选择依赖module的版本时有一套机制,比如最小版本选择等,Go 1.21以后,go工具链版本的选择,也有一套类似的逻辑。接下来我们就来简单看一下。

3. module依赖的Go toolchain版本的选择过程

我们先来回顾一下go module中依赖module的版本选择机制:最小版本选择(mvs),下面的图是讲解这个机制时经常引用的图:


上图来自https://go.dev/ref/mod

以module C的版本选择为例,A依赖C 1.3,B依赖C 1.4,那么满足应用依赖需求的最小版本就是1.4。如果选择1.3,则不满足B对依赖的要求。

对Go toolchain的选择过程也遵循mvs方法,我们把前面的那个例子拿过来:

现在我们帮这个例子选择go toolchain版本。

注:如果go.mod中没有显式用toolchain指示工具链版本,那我们可以认为go.mod中有一个隐含的toolchain指示版本,该版本与go directive指示的版本一致。

上面的例子中对toolchain version的最高要求为module D的go 1.21.0,当startup toolchain(执行的那个go命令的版本)得到这个信息后,就会在当前可用的toolchain版本列表中选出满足go 1.21.0的最小版本的go toolchain,然后会有一个叫Go toolchain switches(Go工具链切换)的过程,切换后,选出的新版go toolchain会继续后面的工作(编译和链接)。例如,如果可用的toolchain版本有如下三个:

  • go 1.22.7
  • go 1.21.3
  • go 1.21.5

那么startup toolchain会根据mvs原则选出满足go 1.21.0的最小版本,即go 1.21.3。

这里大家可能会马上问:什么是可用的toolchain版本?别急!接下来我们就来回答这个问题。

4. GOTOOLCHAIN环境变量与toolchain版本选择

是否执行自动工具链下载和缓存、Go toolchain switches(Go工具链切换)以及切换的工具链的版本取决于GOTOOLCHAIN环境变量的设置、go.mod中go和toolchain指示的版本。

当go命令捆绑的工具链与module的go.mod的go或工具链版本一样时或更新时,go命令会使用自己的捆绑工具链。例如,当在main module的go.mod包含有go 1.21.0时,如果go命令绑定的工具链是Go 1.21.3版本,那么将继续使用初始toolchain的版本,即Go 1.21.3。

而如果go.mod中的go版本写着go 1.21.9,那么go命令捆绑的工具链版本1.21.3显然不能满足要求,那此时就要看GOTOOLCHAIN环境变量的配置。

GOTOOLCHAIN的设置以及对结果的影响略复杂,下面是GOTOOLCHAIN的多种设置形式以及对toolchain选择的影响说明(以下示例中本地go命令捆绑的工具链版本为Go 1.21.0):

  • \<name>

例如,GOTOOLCHAIN=go1.21.0。go命令将始终运行该特定版本的go工具链。如果本地存在该版本工具链,就使用本地的。如果不存在,会下载、缓存起来并使用。如果go.mod中的工具链版本高于name版本,则停止编译:

$cat go.mod
module demo1

go 1.23.1
toolchain go1.23.1 

$GOTOOLCHAIN=go1.21.0 go build
go: go.mod requires go >= 1.23.1 (running go 1.21.0; GOTOOLCHAIN=go1.21.0)
  • \<name>+auto

当GOTOOLCHAIN设置为\<name>+auto时,go命令会根据需要选择并运行较新的Go版本。具体来说,它会查询go.mod文件中的工具链版本和go version。如果go.mod 文件中有toolchain行,且toolchain指示的版本比默认的Go工具链(name)新,那么系统就会调用toolchain指示的工具链版本;反之会使用默认工具链。

当本地不存在决策后的工具链版本时,会自动下载、缓存,并使用该缓存工具链进行后续编译。

$cat go.mod
module demo1

go 1.23.1
toolchain go1.23.1 

$GOTOOLCHAIN=go1.24.1+auto go build
go: downloading go1.24.1 (darwin/amd64) // 使用name指定工具链,但该工具链本地不存在,于是下载。

$GOTOOLCHAIN=go1.20.1+auto go build
go: downloading go1.23.1 (darwin/amd64) // 使用go.mod中的版本的工具链
  • \<name>+path

当GOTOOLCHAIN设置为\<name>+path时,go命令会根据需要选择并运行较新的Go版本。具体来说,它会查询go.mod文件中的工具链版本和go version。如果go.mod 文件中有toolchain行,且toolchain指示的版本比默认的Go工具链(name)新,那么系统就会调用toolchain指示的工具链版本;反之会使用默认工具链。当使用\<name>+path时,如果决策得到的工具链版本在PATH路径下没有找到,那么go命令执行过程将终止。

$cat go.mod
module demo1

go 1.23.1
toolchain go1.23.1 

$GOTOOLCHAIN=go1.24.1+path go build // 使用name指定工具链,但该工具链本地不存在,于是编译停止
go: cannot find "go1.24.1" in PATH

$GOTOOLCHAIN=go1.20.1+path go build // 使用go.mod中的版本的工具链,但该工具链本地不存在,于是编译停止
go: cannot find "go1.23.1" in PATH
  • auto (等价于 local+auto,这也是默认值)

auto的语义是当go.mod中工具链版本低于go命令捆绑的工具链版本,则使用go命令运行捆绑的工具链;反之,自动下载对应的工具链版本,缓存起来并使用。

$cat go.mod
module demo1

go 1.23.1
toolchain go1.23.1 

$GOTOOLCHAIN=auto go build
go: downloading go1.23.1 (darwin/amd64)
  • path (等价于 local+path)

path的语义是当go.mod中工具链版本低于go命令捆绑的工具链版本,则使用go命令运行捆绑的工具链;反之,在PATH中找到满足go.mod中工具链版本的go版本。如果没找到,则会停止编译过程:

$cat go.mod
module demo1

go 1.23.1
toolchain go1.23.1 

$GOTOOLCHAIN=path go build
go: cannot find "go1.23.1" in PATH
  • local

当GOTOOLCHAIN设置为local时,go命令总是运行捆绑的 Go 工具链。如果go.mod中工具链版本高于local的版本,则会停止编译过程。

$cat go.mod
module demo1

go 1.23.1
toolchain go1.23.1 

$GOTOOLCHAIN=local go build
go: go.mod requires go >= 1.23.1 (running go 1.21.0; GOTOOLCHAIN=local)

就像之前说的,当Go工具在编译module依赖项时发现当前go toolchain版本无法满足要求时,会进行go toolchain switches(切换),切换的过程就是从可用的go toolchain列表中取出一个最适合的。

那么“可用的go toolchain列表”究竟是如何组成的呢? go命令有三个候选版本(以当前发布的最新版Go 1.21.1为例,这些版本也是Go当前承诺提供support的版本):

  • 尚未发布的Go语言版本的最新候选版本(1.22rc1)
  • 最近发布的 Go 语言版本的最新补丁 (1.21.1)
  • 上一个Go语言版本的最新补丁版本(1.20.8)。

当GOTOOLCHAIN设置为带auto形式的值的时候,Go会下载这些版本;当GOTOOLCHAIN设置为代path形式的值的时候,Go会在PATH路径搜索适合的go工具链列表。

接下来,go会用mvs(最小版本选择)来确定究竟使用哪个toolchain版本。Go toolchain reference中就有这样一个例子。

假设example.com/widget@v1.2.3需要Go 1.24rc1或更高版本。go命令会获取可用工具链列表,并发现两个最新Go工具链的最新补丁版本是Go 1.28.3和Go 1.27.9,候选版本Go 1.29rc2也可用。在这种情况下,go 命令会选择Go 1.27.9。

如果 widget 需要 Go 1.28或更高版本,go命令会选择 Go 1.28.3,因为 Go 1.27.9 太旧了。如果widget需要Go 1.29或更高版本,go命令会选择Go 1.29rc2,因为Go 1.27.9和Go 1.28.3都太老了。

5. 小结

Go 1.21通过增强go语句语义和添加工具链管理,大幅改进了Go语言的向前兼容性。开发者可以放心使用新语言特性,无需担心旧版本编译器带来的问题。go命令会自动处理不同module使用不同go版本和不同工具链版本的情况,使用Go语言变得更简单。

总之,要理解本文内容,重要的是要把握住一点:Go 1.21版本对Go向前兼容性的改进是参考了go module对依赖的管理方法:即将go版本和go toolchain版本作为一个module的“依赖”来管理

6. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

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

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系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

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats