本文永久链接 – 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)，下面的图是讲解这个机制时经常引用的图：

以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. 参考资料

• Forward Compatibility and Toolchain Management in Go 1.21 – https://go.dev/blog/toolchain
• Go Toolchains reference – https://go.dev/doc/toolchain

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

著名云主机服务厂商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

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

本文永久链接 – https://tonybai.com/2023/04/26/go-1-21-foresight

Go 1.21版本正在如火如荼地开发当中，按照Go核心团队的一年两次的发布节奏来算，Go 1.21版本预计将在2023年8月发布(Go 1.20版本是在2023年2月份发布的)。

本文将和大家一起看看Go 1.21都会带来哪些新特性。不过由于目前为时尚早，下面列出的有些变化最终不一定能进入到Go 1.21的最终版本中，所以切记一切变更要以最终Go 1.21版本发布时为准。

在细数变化之前，我们先来看看Go语言的当前状态。

1. Go语言当前状态

在《2022年Go语言盘点》一文中，我们提到年初Go语言的2022年终排名为12位，同时TIOBE官方编辑也提到：“在新兴编程语言中，Go是唯一一个可能在未来冲入前十的后端编程语言”。Go语言的发展似乎应验了这一预测，在今年的3月份，Go就再次进入编程语言排行榜前十：

一个月后的四月初，TIOBE排行榜上，Go稳住了第10名的位次：

在国内，在鹅厂前不久发布的《2022年腾讯研发大数据报告》中，

在国内，继Go在2021年从C++手中夺过红旗首次登顶鹅厂最热门编程语言之后，在鹅厂前不久发布的《2022年腾讯研发大数据报告》中，Go蝉联鹅厂最热门编程语言，继续夯实在国内头部互联网公司内的优势地位：

Go于2009年开源，在经历多年的宣传和鼓吹后，Go目前进入了平稳发展的阶段。疫情结束后，原先线上举办或取消的国内外的Go技术大会现在陆续又都开始恢复了，相信这会让更多开发人员接触到Go。像Go这样的能在世界各地持续多年举办技术大会的语言真是不多了。

接下来，我们就来聚焦到Go 1.21版本，挖掘一下这个版本都有哪些新特性。

2. 语言变化

目前Go 1.21版本里程碑中涉及语言变化的有大约2项，我们来看看。

2.1 增加clear预定义函数

Go 1.21增加了一个clear预定义函数用来做切片和map的clear操作，其原型如下：

// $GOROOT/src/builtin.go

// The clear built-in function clears maps and slices.
// For maps, clear deletes all entries, resulting in an empty map.
// For slices, clear sets all elements up to the length of the slice
// to the zero value of the respective element type. If the argument
// type is a type parameter, the type parameter's type set must
// contain only map or slice types, and clear performs the operation
// implied by the type argument.
func clear[T ~[]Type | ~map[Type]Type1](t T)

clear是针对map和slice的操作函数，它的语义是什么呢？我们通过一个例子来看一下：

package main

import "fmt"

func main() {
    var sl = []int{1, 2, 3, 4, 5, 6}
    fmt.Printf("before clear, sl=%v, len(sl)=%d, cap(sl)=%d\n", sl, len(sl), cap(sl))
    clear(sl)
    fmt.Printf("after clear, sl=%v, len(sl)=%d, cap(sl)=%d\n", sl, len(sl), cap(sl))

    var m = map[string]int{
        "tony": 13,
        "tom":  14,
        "amy":  15,
    }
    fmt.Printf("before clear, m=%v, len(m)=%d\n", m, len(m))
    clear(m)
    fmt.Printf("after clear, m=%v, len(m)=%d\n", m, len(m))
}

运行该程序：

before clear, sl=[1 2 3 4 5 6], len(sl)=6, cap(sl)=6
after clear, sl=[0 0 0 0 0 0], len(sl)=6, cap(sl)=6
before clear, m=map[amy:15 tom:14 tony:13], len(m)=3
after clear, m=map[], len(m)=0

我们看到：

• 针对slice，clear保持slice的长度和容量，但将所有slice内已存在的元素(len个)都置为元素类型的零值；
• 针对map，clear则是清空所有map的键值对，clear后，我们将得到一个empty map。

2.2 改变panic(nil)语义

使用defer+recover捕获panic是Go语言唯一处理panic的方法，其典型模式如下：

package main

import "fmt"

func foo() {
    defer func() {
        if err := recover(); err != nil {
            fmt.Printf("panicked: %v\n", err)
            return
        }
        fmt.Println("it's ok")
    }()

    panic("some error")
}

func main() {
    foo()
}

运行上面程序会输出：

panicked: some error

例子中我们向panic传入了表示panic原因的字符串，panic的参数是一个interface{}类型，可以传入任意值，当然也可以传入nil。

比如上面例子，当我们给foo函数的panic调用传入nil时，我们将得到下面结果：

it's ok

这可能会给开发者带去疑惑：明明是触发了panic，但函数却按照正常逻辑处理！2018年，前Go核心团队成员bradfitz就提出了一个issue：spec: guarantee non-nil return value from recover，提出当开发者调用panic(nil)时，recover应该返回某种runtime error，而不是nil。这个issue在今年被纳入了Go 1.21版本，现在该issue的实现已经被merge到了主干。

新的实现在src/runtime/panic.go中定义了一个名为PanicNilError的新Error：

// $GOROOT/src/runtime/panic.go

// A PanicNilError happens when code calls panic(nil).
//
// Before Go 1.21, programs that called panic(nil) observed recover returning nil.
// Starting in Go 1.21, programs that call panic(nil) observe recover returning a *PanicNilError.
// Programs can change back to the old behavior by setting GODEBUG=panicnil=1.
type PanicNilError struct {
    // This field makes PanicNilError structurally different from
    // any other struct in this package, and the _ makes it different
    // from any struct in other packages too.
    // This avoids any accidental conversions being possible
    // between this struct and some other struct sharing the same fields,
    // like happened in go.dev/issue/56603.
    _ [0]*PanicNilError
}

func (*PanicNilError) Error() string { return "panic called with nil argument" }
func (*PanicNilError) RuntimeError() {}

Go编译器会将panic(nil)替换为panic(new(runtime.PanicNilError))，这样我们用Go 1.21版本运行上面的程序，我们就会得到下面结果了：

panicked: panic called with nil argument

如果你的遗留代码中调用了panic(nil)(注：显然这不是一种很idiomatic的作法)，升级到Go 1.21版本后你就要小心了。如果你想保留原先的panic(nil)行为，可以用GODEBUG=panicnil=1。

有童鞋可能会质疑这违反了Go1兼容性承诺，但实际上Go1兼容性规范保留了对语言规范中不一致或错误的修订权力，即便这种修订会导致遗留代码出现与原先不一致的行为。

3. 编译器与工具链

每个Go版本中，编译器和工具链的改动都不少，我们挑重点看一下：

3.1 一些OS的最小支持版本的更新

Go 1.21开始，go installer支持最小macOS版本更新为10.15，而最小Windows版本为Windows 10。

3.2 低版本的go编译器将拒绝编译高版本的go module

从Go 1.21版本开始，低版本的go编译器将拒绝编译高版本的go module(go.mod中go version标识最低版本) ，这也是Russ Cox策划的Go扩展的向前兼容性提案的一部分。此外，Go扩展向前兼容性提案感觉比较复杂，可能不会全部在Go 1.21版本落地。

3.3 支持WASI

Go从1.11版本就开始支持将Go源码编译为wasm二进制文件，并在支持wasm的浏览器环境中运行。

不过WebAssembly绝不仅仅被设计为仅限于在Web浏览器中运行，核心的WebAssembly语言是独立于其周围环境的，WebAssembly完全可以通过API与外部世界互动。在Web上，它自然使用浏览器提供的现有Web API。然而，在浏览器之外，之前还没有一套标准的API可以让WebAssembly程序使用。这使得创建真正可移植的非Web WebAssembly程序变得困难。WebAssembly System Interface(WASI)是一个填补这一空白的倡议，它有一套干净的API，可以由多个引擎在多个平台上实现，并且不依赖于浏览器的功能（尽管它们仍然可以在浏览器中运行）。

Go 1.21将增加对WASI的支持，初期先支持WASI Preview1版本，之后会支持WASI Preview2版本，直至最终WASI API版本发布！目前我们可以使用GOOS=wasip1 GOARCH=wasm将Go源码编译为支持WASI的wasm程序，下面是一个例子：

// main.go
package main            

func main() {
    println("hello")
}

下载最新go dev版本后(go install http://golang.org/dl/gotip@latest)，可以执行下面命令将main.go编译为wasm程序：

$ GOARCH=wasm GOOS=wasip1 gotip build -o main.wasm main.go

开源的wasm运行时有很多，wazero是目前比较火的且使用纯Go实现的wasm运行时程序，安装wazero后，可以用来执行上面编译出来的main.wasm：

$curl https://wazero.io/install.sh
$wazero run main.wasm
hello

3.4 Go 1.21可能推出纯静态工具链，不再依赖glibc

使用纯Go实现的net resolver，原先DNS的问题也将被解决，这样Go团队很可能在构建工具链的时候使用CGO_ENABLED=0构建出静态工具链，没有动态链接库的依赖。

3.5 go test -c支持为多个包同时构建测试二进制程序

Go 1.21版本之前，go test -c仅支持将单个包的测试代码编译为测试二进制程序，Go 1.21版本则允许我们同时为多个包构建测试二进制程序。

下面是官方给出的例子：

$ go test -c -o /tmp ./pkg1 ./pkg2 ./pkg2
$ ls /tmp
pkg1.test pkg2.test pkg3.test

3.6 增加\$GOROOT/go.env

今天使用go env -w命令修改的默认环境变量会写入：filepath.Join(os.UserConfigDir(), “go/env”)。在Mac上，这个路径是\$HOME/Library/Application Support/go/env；在Linux上，这个路径是\$HOME/.config/go/env。

Go 1.21将增加一个全局层次上的go.env，放在\$GOROOT下面，目前默认的go.env为：

// $GOROOT/go.env

# This file contains the initial defaults for go command configuration.
# Values set by 'go env -w' and written to the user's go/env file override these.
# The environment overrides everything else.

# Use the Go module mirror and checksum database by default.
# See https://proxy.golang.org for details.
GOPROXY=https://proxy.golang.org,direct
GOSUMDB=sum.golang.org

我们仍然可以通过go env -w命令修改user级的env文件来覆盖上述配置，当然最高优先级的是OS用户环境变量，如果在OS用户环境变量文件(比如.bash_profile、.bashrc)中设置了Go的环境变量值，比如GOPROXY等，那么以OS用户环境变量为优先。

4. 标准库

我们接下来再来看看变更最多的一部分：标准库，我们将对主要变更项作简要介绍。

4.1 slices和maps进入标准库

Go 1.18版本泛型落地发布前的最后一刻，Rob Pike叫停了slices、maps等泛型包的入库，后来这两个包先放置在golang.org/x/exp下作为实验包。随着Go泛型日益成熟以及Go团队对泛型使用经验的增多，Go团队终于决定将golang.org/x/exp/slices和golang.org/x/exp/maps在Go 1.21版本中将挪入标准库。

4.2 log/slog加入标准库

log/slog是Go官方版结构化日志包，大致与uber的zap包相当。在我之前的一篇文章《slog：Go官方版结构化日志包》有对slog的详尽说明，大家可以移步到那篇文章看看。不过slog的proposal依旧很多，后续slog可能会有持续改进和变更，与那篇文章中的内容可能会有一些差异。

4.3 sync包增加OnceFunc、OnceValue和OnceValues

在sync.Once的基础上，这个issue增加了三个与Once相关的”语法糖”API，用在一些对Once有需求的最常见的场景中。

4.4 增加testing.Testing函数

Go 1.21为testing包增加了func Testing() bool函数，该函数可以用来报告当前程序是否是go test创建的测试程序。使用Testing函数，我们可以确保一些无需在单测阶段执行的函数不被执行。比如下面例子来自这个issue：

// file/that/should/not/be/used/from/testing.go

func prodEnvironmentData() *Environment {
    if testing.Testing() {
        log.Fatal("Using production data in unit tests")
    }
    ....
}

4.5 一些变更点

• context: 增加为deadline或timeout context设置cancel原因的API – https://github.com/golang/go/issues/56661
• unicode升级到15.0版本 – https://github.com/golang/go/issues/55079

5. 参考资料

• Go 1.21 milestone – https://github.com/golang/go/milestone/279

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

著名云主机服务厂商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
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite

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