一种可能性是添加另一个 -buildmode,例如 -buildmode=c-header,它可以执行所需的任何工作(并可能将额外的产物写入 GOCACHE ),但只发出(或安装)头文件而不是整个存档。
这可以作为具有特定包参数的 go tool cgo 调用的更直接替代品。

另一个选项可能是让-i标志抑制标准库目标的错误，这样即使GOROOT不可写，go install -i命令也能正常工作。

https://golang.org/cl/208117提到了这个问题：misc/cgo/testcarchive: avoid writing to GOROOT in tests

https://golang.org/cl/208119提到了这个问题：misc/cgo/testcshared: avoid writing to GOROOT in tests

我们可以让 go install 安装所有导入包的头文件，即使没有 -i 也可以。这将改变行为，但仅限于不是 main 但已导出函数的包，这种情况比较少见。

也许吧，但导入本身似乎有点牵强附会：如果C代码使用了来自包a的标识符，那么构建过程应该提到包a,而不是恰好导入了a的其他包b。
另一方面，我想C库必须链接到某个(共享或归档)文件，该文件是由包main生成的，所以让go install为链接到该包的所有标识符生成所有头文件似乎并不糟糕。

在这个问题中，用户想要在不同的文件中使用类型别名 type T1 = T2,但是遇到了一些问题。以下是翻译后的文本内容：

任何进展吗？我正在尝试使用 bcmills@ 建议的解决方法，即使用 go tool cgo -exportheader,所以我的构建脚本包括：

go tool cgo -exportheader ${CGO_BUILD_ROOT}/foo.h foo.go
&& go tool cgo -exportheader ${CGO_BUILD_ROOT}/bar.h bar.go
&& go build -buildmode=c-shared -o ${LIB_FULL_PATH}
&& rm -rf _obj

其中 foo.go 和 bar.go 都位于同一个包中。这之前运行得很好，直到我尝试使用类型别名时。
我想定义一个类型别名 type T1 = T2,并在 foo.go 和 bar.go 中使用它。
如果我在 foo.go 中定义了这个别名，go build 可以正常工作，就像预期的那样(T1 在 bar.go 的作用域内)。然而，导出 bar.go 的头文件失败了，而 unrecognized Go type T1 可以正常工作。
如果我在 foo.go 和 bar.go 中定义了相同的别名，那么这两个文件的导出头文件都可以成功，但是在 go build 中会出现重复声明错误(并不奇怪)。