这是个非常典型的Go编译场景困惑，我来帮你拆解背后的核心原因：

核心逻辑：CGO_ENABLED=1的行为取决于「是否实际存在C依赖」 #

当你设置CGO_ENABLED=1时，Go编译器只是允许调用C代码和依赖C库，但最终的链接方式（静态/动态）还要看两个关键因素：

• 你的代码（或依赖的第三方库）是否真的引入了CGO相关的功能/C依赖
• 编译参数是否能满足静态链接所有C依赖的要求

你的两个程序的差异分析 #

第一个程序（CGO_ENABLED=1时生成动态链接）

你用了--ldflags='-extldflags=-static'和--installsuffix cgo参数，但还是生成了带动态依赖的二进制，大概率是因为：

• 你的代码或依赖的github.com/ourrepo库中实际使用了CGO（比如调用了C函数、用了net包依赖系统DNS解析的CGO实现，或者引入了依赖C库的第三方包）
• 当存在C依赖时，-extldflags=-static要求链接器静态链接这些C库，但如果你的编译环境中没有对应C库的静态版本（比如某些系统库只提供动态库），链接器会自动 fallback 到动态链接，最终导致二进制依然带有动态依赖。

而当你把CGO_ENABLED=0关掉后，Go会强制禁用所有CGO功能，编译纯Go代码，自然生成完全静态的二进制——这也是最稳妥的纯Go静态编译方式。

第二个程序（CGO_ENABLED=1时生成静态链接）

这个程序虽然开了CGO_ENABLED=1，但实际上没有任何CGO依赖：

• 代码是纯Go实现，没有调用C函数，也没有引入需要CGO的第三方库
• 这种情况下，Go编译器会跳过所有CGO相关的链接步骤，相当于“假开启”CGO，此时-extldflags=-static参数没有实际作用，最终生成的二进制和CGO_ENABLED=0时的效果一致——纯Go静态链接。

验证和排查方法 #

你可以用以下命令确认问题：

1. 检查项目是否存在CGO依赖：

   go list -deps -f '{{.CgoFiles}}' ./...
   

   如果输出非空字符串，说明项目确实有CGO相关的代码文件。
2. 查看二进制的动态依赖：

   ldd program
   

   输出中列出的就是动态链接的库，你可以针对性地检查这些库的静态版本是否存在于编译环境中。

更可靠的编译建议 #

• 如果不需要CGO：直接用CGO_ENABLED=0编译，这是生成完全静态二进制最稳妥的方式，避免任何意外的动态依赖：

  env GOOS=linux CGO_ENABLED=0 GO111MODULE=on GOPRIVATE=github.com/ourrepo GOPROXY=https://proxy.golang.org go build -o program main.go
  

• 如果必须用CGO且需要静态链接：
  • 确保编译环境中安装了所有依赖C库的静态版本（比如Debian/Ubuntu上部分库需要安装libxxx-static包）
  • 若遇到glibc静态链接的问题，可以考虑用Alpine Linux（基于musl libc）作为编译环境，musl对静态链接的支持更好，能生成完全静态的二进制。

内容的提问来源于stack exchange，提问作者Thomas