关于go:还能这样玩Go-将会增强-Go1-向前兼容性

大家好，我是煎鱼。

年前咱们在《醒醒吧，将来不会有 Go2 了！》文章中探讨了 Go2 的将来，明确了将来是以 Go1.x.y 为主的 Go1 时代。

为了实现这个北极星指标，Go 团队采取的策略别离是：加强 Go1 向后兼容（在前文已分享）和 Go1 向前兼容（本文重点内容）。

本次要提到的“向前兼容”，指的是 旧版本的 Go 编译新的 Go 代码。这个方向比拟少被议论，甚至特意设计。

Go 团队的大当家 Russ Cox，针对如下几个方面做了新设计和调整，输入了《Proposal: Extended forwards compatibility in Go》，曾经失去探讨，很大概率落地。

局部重点如下：

咱们会在 go module 生成时，在 Go 工程下生成一个 go.mod 文件。其中会蕴含一个 go 行，将会申明该模块应该利用的 go 版本语义是什么版本。

如下图，申明的是 go1.13：

在该提案落地后，本地装置的 Go 工具链如果比 go 行所申明的 go 版本新时，它将会间接提供所要求的旧语义，而不会从新下载和调用一个旧版本的 Go 工具链。

但如果 go 行申明了一个较新的 Go 工具链，那么本地装置的 Go 工具链就会下载并运行较新的工具链来满足其需要。

以下是一个例子。

在例子中，咱们正在运行的版本是 go1.30。但在模块中，有一个 go.mod 申明了 go 版本：

go 1.30.1

Go1.30 会下载并调用 go1.30.1 来实现命令，因为模块中要求的 go 版本比本地装置的更高。

但如果 go.mod 文件中申明的是：

go 1.20rc1

Go1.30 将本人提供 go1.20rc1 语义，而不是运行 go1.20 rc1 工具链。因为本地装置的版本更新，能够通过 GODEBUG 来满足旧语义的诉求。

可能会有同学想要运行更新版本的 Go 工具链，但 Go 语义上还是应用旧版本。

为了满足这点诉求，go.mod 文件也会反对 toolchain 行的设置，以此来反对新版本的工具链的应用。

如果 go.mod 文件中设置了 toolchain 行，将指定应用的工具链版本，go 行只指定语言语义的 Go 版本。

go.mod 文件如下：

go 1.18
toolchain go1.20rc1

作用是将为这个模块抉择 go1.18 的语义，应用 go1.20rc1 的工具链来构建利用。

将会在 Go 工具链新增 GOTOOLCHAIN 环境变量的设置和应用能够应用 go env -w 设置。也能够在 go test 时做如下调整：

GOTOOLCHAIN=go1.17.2 go test

go build 编译时能够：

GOTOOLCHAIN=go1.18rc1 go build -o myprog.exe

可能会有同学纳闷 GOTOOLCHAIN 的默认值哪来，有哪些值？

GOTOOLCHAIN 环境变量的默认值取决于 Go 工具链。规范 Go 发行版默认为 GOTOOLCHAIN=auto，也就是将控制权交给 go.mod 文件。这是在施行这个提案后 99% 会看到的默认行为。

Go 工具链的一揽子货色里也比拟多，例如：go get 命令，也会对 go.mod 文件中的 go 版本或 toolchain 行进行变更，以配合应用。

在明天这篇文章中，咱们介绍了 Go1 兼容性加强中的“向前兼容”局部，其中要点是：加大对 go.mod 文件中的 go 行和 toolchain 行和工具链 GOTOOLCHAIN 相干的利用。

外围目标是为了将 go 语法语义和 go 工具链的版本申明公开出来，达到隔离应用。再配合“向后兼容”中的 GODEBUG 的应用，让 Go 语言做兼容性时有更多更大的应用空间来实现机制上的保障。

这么一来，Go 语言在这一块会变得异样简单，了解老本也会变高。心愿大家后续在这块也不要再踩坑了。

文章继续更新，能够微信搜【脑子进煎鱼了】浏览，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言能够看 Go 学习地图和路线，欢送 Star 催更。

Go1 向前兼容