Golang中为什么依赖项最大版本限制规则也适用于低于1.21的go指令？

Golang中为什么依赖项最大版本限制规则也适用于低于1.21的go指令？ 主模块 go.mod 文件中的 go 指令 文档 说明了以下内容：

在 go 1.21 或更高版本时：

  • …
  • go 行必须大于或等于所有依赖项的 go 行。
  • …

因此，基于此，如果主模块 go.mod 文件中的 go 指令小于主模块导入（直接/间接）的任何模块的 go 指令，构建将会失败。这里需要强调的是，此规则仅当主模块 go.mod 文件中的 go 指令大于或等于 go 1.21.0 时才适用。 所以，如果主模块 go.mod 文件中的 go 指令设置为 go 1.21.0，而它包含的某个模块在其 go.mod 文件中设置了 go 1.22.0，构建将会失败。这一点我很清楚。

让我困惑的是，出于某种原因，即使主模块 go.mod 文件中的 go 指令设置为低于 1.21.0 的版本，例如 go 1.20.0，此规则也仍然适用。这与文档中的陈述相悖。

例如，请看以下示例模块（我仅为演示目的创建）。它的 go 指令设置为 go 1.22.0。

如果你从 go 指令设置为 go 1.22.0 的主模块导入该模块，一切工作正常。另一方面，如果主模块中的 go 指令设置为 go 1.21.0，构建将无法工作。这也是预期的，因为它违反了要求。奇怪的是，如果你将主模块中的 go 指令设置为 go 1.20.0 或更低的版本，它仍然无法工作，而根据文档，它应该可以工作，因为上述规则不适用于低于 go 1.21.0 的 go 指令。

这里发生了什么？

顺便说一下，我使用的是 Go 工具链 1.22。


更多关于Golang中为什么依赖项最大版本限制规则也适用于低于1.21的go指令？的实战教程也可以访问 https://www.itying.com/category-94-b0.html

5 回复

go.mod 文件中的 go 指令起到最低要求的作用。依赖项的 go 指令版本高于主模块时，将导致构建失败。

更多关于Golang中为什么依赖项最大版本限制规则也适用于低于1.21的go指令？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


哦，哇。感谢如此全面的调查。这显然改变了我的理解，因为之前我并不了解这些细节 :+1:t2:

你好。

What is emphasized here is that this rule only applies if the go directive in the go.mod file of the main module is greater than or equal to go 1.21.0

这里强调的并非如此。文档说明的是该特性被实现的语言版本。这与 go.mod 文件中的版本无关，而是关于正在使用的编译器版本。Go 语言从未提供过为未来版本编译包的能力。因此，错误信息过去看起来是这样的：

$ go version
go version go1.20.14 linux/arm64
$ go run main.go 
github.com/leabit/moduleA/package1: cannot compile Go 1.22 code

尽管 go mod tidy 命令运行正常

从 go1.21 开始，这个错误信息被修改为更恰当的解释：

$ go version
go version go1.21.7 linux/arm64
$ go mod tidy
go: finding module for package github.com/leabit/moduleA/package1
go: toolchain upgrade needed to resolve github.com/leabit/moduleA/package1
go: github.com/leabit/moduleA@v1.0.0 requires go >= 1.22.0 (running go 1.21.7; GOTOOLCHAIN=local)

实际上，Golang编译器（工具链）以前能够编译未来版本的语言。他们在Go 1.21中加入了关于版本的限制。然而，类似的限制也存在于从Go 1.19.13开始的Go 1.19版本以及从Go 1.20.8开始的Go 1.20版本中。具体来说，更高的版本（从补丁13开始的1.19版本和从补丁8开始的1.20版本）会拒绝加载声明版本为Go 1.22及以上的模块。更多细节请查看 Go工具链 - Go编程语言 中的“模块和工作区配置”部分。

引用：

在Go 1.21之前，Go工具链将 go 行视为建议性要求：如果构建成功，工具链就认为一切正常；如果不成功，它会打印一条关于潜在版本不匹配的说明。Go 1.21将 go 行改为强制性要求。这种行为部分向后移植到了更早的语言版本：从Go 1.19.13开始的Go 1.19版本以及从Go 1.20.8开始的Go 1.20版本，会拒绝加载声明版本为Go 1.22或更高的工作区或模块。

关于我的问题（涉及Go 1.22工具链的行为）：

经过一些研究，我发现我之所以不能（例如）使用 go 指令 1.20 并同时使用版本高于或等于 go 1.21 的模块，是因为这被认为是一种有问题的行为。由于Go 1.21引入了关于版本的规则，即使主模块指定为 go 1.20（对此版本限制不适用），你仍然导入了适用此限制的版本（例如 go 1.21），因此Go 1.21及更高版本（在我的案例中是1.22）的工具链将其视为错误并禁用它。然而，如果你指定一些较低的版本，一切仍然会按预期工作。例如，如果你的主模块设置为 go 1.13，并且你导入了版本为 go 1.20 的模块（任何低于引入此限制的 go 1.21 的版本），一切都能正常工作。

在 Go 1.21 之前，go 指令主要用于选择编译器和标准库的版本，对依赖项的 go 指令没有强制约束。但从 Go 1.21 开始，引入了最小版本选择（MVS）的增强，其中包含了对依赖项 go 指令的检查。

关键点在于：即使主模块的 go 指令低于 1.21，但如果你使用的是 Go 1.22 工具链，工具链会应用当前版本的规则。工具链的版本决定了实际执行的行为，而不是主模块的 go 指令。

示例验证：

创建主模块 go.mod：

module main

go 1.20  // 低于 1.21

require github.com/leabit/moduleA v0.0.1

创建 main.go：

package main

import "github.com/leabit/moduleA"

func main() {
    moduleA.Print()
}

使用 Go 1.22 工具链运行：

go mod tidy
go run main.go

输出错误：

go: github.com/leabit/moduleA@v0.0.1 requires go >= 1.22

这是因为 Go 1.22 工具链会检查依赖项的 go 指令是否兼容。依赖项 moduleA 声明了 go 1.22，而主模块的 go 1.20 低于此要求，因此构建失败。

即使主模块的 go 指令是 1.20，工具链仍然执行了版本检查。这是工具链的行为，而非文档中描述的仅当主模块 go 指令 ≥ 1.21 时才应用的规则。

根本原因：工具链版本主导了检查逻辑。Go 1.22 工具链会强制执行依赖项的 go 指令约束，无论主模块的 go 指令是多少。

如果你降级到 Go 1.20 工具链，则不会进行此检查，构建可能成功（假设依赖项兼容 Go 1.20）。但使用 Go 1.22 工具链时，它应用了当前工具链的规则。

因此，文档中的描述应理解为：从 Go 1.21 开始引入了此规则，但工具链会向后应用此规则到所有模块，无论其 go 指令如何。

回到顶部