这是按照预期工作的，参考 #12808

@seankhliao 这种行为并不完全体现在make.bash的当前文档中。

CGO_ENABLED: 控制构建过程中的cgo使用。将其设置为1以包含所有与cgo相关的文件，即带有"cgo"构建指令的.c和.go文件。将其设置为0以忽略它们。

这并不清楚它实际上会在生成的编译器中烧录一个默认值。可能需要两个不同的标志：

1. 在编译过程中是否应该启用cgo?
2. 应该将哪个默认值烧录到生成的编译器中？
   请重新打开此问题。

当前行为按预期工作。我们今天不会改变CGO_ENABLED的工作方式。
重新打开以澄清文档。

我们今天不会改变CGO_ENABLED的工作方式。
@ianlancetaylor 我希望你能重新考虑一下这个问题。今天，如果我从Alpine镜像构建一个针对Linux的编译器(是的，我知道这还不完全受支持),那么我的选择有以下两种：

1. 使用CGO_ENABLED=0构建，这会产生一个默认不执行cgo的编译器，但会产生意想不到的副作用。
2. 不使用CGO_ENABLED=0构建，生成一个无法使用的编译器，它与musl链接。
   我认为如果有CGO_ENABLED_FOR_$GOOS_$GOARCH环境变量，会更合理(也更一致),这些环境变量可以为构建的编译器设置默认值。这样可以实现两个目标：
3. 就我的情况而言，我会使用CGO_ENABLED=0 CGO_ENABLED_FOR_linux_amd64=1并得到预期的结果。
4. 目前设置了CC_FOR_$GOOS_$GOARCH的人可以通过不为他们预先选择的C编译器的目标显式设置CGO_ENABLED=1来提高他们的体验。

我不反对添加 CGO_ENABLED_FOR_${GOOS}_$(GOARCH} ,或者更简单地说，添加 CGO_ENABLED_FOR_TARGET 。我反对的是改变 CGO_ENABLED 当前的意义。

我们正在计划对cgo在std中的处理方式进行一些更改，届时可能值得重新审视这种行为。目前我们应该暂时搁置这个问题。

对于那些寻找原始问题解决方法的人，在linux/amd64上，你可以明确地将GOHOSTARCH=386设置为欺骗make.bash,让它认为正在进行交叉编译，因此它将生成一个默认启用cgo的没有cgo的编译器。请注意，你还需要安装gcc-multilib,因为引导编译器仍然会使用cgo进行编译。