`//go:build` 和 `// +build` 指令之间有什么区别？

Question

例如，https : //github.com/golang/sys/blob/master/cpu/cpu_gccgo_x86.go#L5：

//go:build (386 || amd64 || amd64p32) && gccgo
// +build 386 amd64 amd64p32
// +build gccgo

package cpu

在我看来，作为构建标签，// +build ... 可以很好地工作。
为什么//go:build仍然明确指定？

顺便说一句，很难找到 的手册//go:build，但// +build很容易（https://pkg.go.dev/cmd/go#hdr-Build_constraints）

Answer 1

//go:build 是 Go 1.17 中引入的新条件编译指令。

它旨在替换// +build指令，因为新语法带来了一些关键改进：

• 与其他现有的 Go 指令和编译指示的一致性，例如 //go:generate
• 支持标准布尔表达式，例如//go:build foo && bar，而旧// +build注释的语法不太直观。例如 AND 用逗号表示，// +build foo,barOR 用空格表示// +build foo bar
• 它由 支持go fmt，它将自动修复源文件中指令的错误位置，从而避免在指令和包语句之间不留空行的常见错误。

这两个构建指令将共存了几围棋的版本中，为了确保平稳过渡，为概述有关建议文件（以下N = 17，重点煤矿）：

Go 1.N 将开始转换。在 Go 1.N 中：

• 构建将开始//go:build首选文件选择行。如果//go:build文件中没有，则任何// +build行仍然适用。

• 如果 Go 文件//go:build不包含// +build.

• 如果 Go 或程序集文件//go:build在文件中包含太晚，构建将失败。Gofmt 会将错位的 //go:build 和 // +build 行移动到文件中的正确位置。

• Gofmt将//go:build使用与其他 Go 布尔表达式（all&&和||运算符周围的空格）相同的规则格式化行中的表达式。

• 如果文件只包含// +build行，gofmt则会//go:build在它们上面添加一个等效的行。

• 如果文件同时包含//go:build和// +build行，gofmt将考虑//go:build真实来源并更新// +build行以匹配，从而保持与 Go 早期版本的兼容性。Gofmt还将拒绝//go:build被认为太复杂而无法转换为// +build格式的行，尽管这种情况很少见。（请注意此项目符号开头的“如果”。Gofmt不会// +build向只有//go:build.的文件添加行 。）

• 在buildtags办理入住手续go vet将增加支持//go:build的约束。当 Go 源文件包含//go:build和// +build具有不同含义的行时，它将失败。如果检查失败，可以运行gofmt -w.

• buildtags当 Go 源文件包含//go:buildwithout// +build并且其包含模块有一个 go 行列出 Go 1.N 之前的版本时，检查也会失败。如果检查失败，可以添加任何// +build行，然后运行gofmt -w，它将用正确的行替换它。或者可以go.mod将 Go 版本升级到 Go 1.N。

有关语法更改的更多信息：Golang 条件编译