Go默认静态链接，无需额外配置；只要未启用cgo（如无import "C"、// #include等），生成的二进制即自带运行时和所有Go依赖，跨平台部署时只需架构匹配即可直接运行。
go build 默认就是静态链接，不需要额外操作
Go 编译器默认使用静态链接，生成的二进制文件自带所有 Go 标准库和纯 Go 第三方依赖（如 github.com/xuri/excelize/v2），不依赖目标机器上的 libc.so.6 或其他动态库。这意味着只要架构匹配（比如 linux/amd64），扔过去就能跑。
常见误判点：看到 ldd ./myapp 输出 not a dynamic executable 就说明是静态的；如果列出一堆 .so 文件，那说明你无意中触发了 cgo —— 比如导入了 net 包（在某些系统上会 fallback 到 cgo DNS 解析）、或代码里写了 // #include、或调用了 C.xxx 函数。
-
CGO_ENABLED=0不是“开启静态链接”，而是“强制禁用 cgo”，从而确保不会意外引入动态依赖 - 即使设置了
CGO_ENABLED=1（默认值），只要没实际用到 cgo，最终仍是静态链接 -
file ./myapp比ldd更可靠：输出含statically linked即为静态
依赖含 cgo 时，静态链接必须设 CGO_ENABLED=0
一旦项目依赖包含 cgo 的模块（比如 github.com/mattn/go-sqlite3、golang.org/x/sys/unix 在部分场景下），默认构建会生成动态链接二进制，依赖系统级 glibc。这时若想跨发行版部署（尤其是 Alpine 或 Distroless 镜像），就必须显式禁用 cgo：
- 编译命令要加环境变量：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o myapp main.go - 禁用后，所有 cgo 调用（包括
net的系统 DNS、os/user查用户信息）会 fallback 到纯 Go 实现，功能可能受限但更可移植 - 某些包（如 SQLite）在
CGO_ENABLED=0下根本无法编译，需改用纯 Go 替代方案（如modernc.org/sqlite）
go.mod 中的依赖不影响静态/动态属性
go.mod 只管 Go 源码依赖的版本和路径，不决定链接方式。无论你 require 的是 v1.9.1 还是 v2.0.0，只要它们是纯 Go 实现，就天然支持静态链接。
立即学习“go语言免费学习笔记（深入）”；
真正起作用的是：源码里有没有 import "C"、有没有 // #cgo 注释、有没有调用 C.malloc 这类符号。
-
go mod tidy不会帮你判断是否用了 cgo，它只管下载和校验 Go 源码 - 私有模块若含 cgo，同样受
CGO_ENABLED控制；配置GOPRIVATE只影响拉取行为，不改变链接逻辑 - 多模块项目中，子模块是否含 cgo，由其自身代码决定，主模块无法覆盖
Alpine 或 Distroless 环境下必须验证静态性
Alpine 默认用 musl libc，而标准 Linux 发行版用 glibc。如果你没禁用 cgo，又在 Alpine 上构建，go build 会失败或生成不可运行的二进制。
安全做法是：在目标环境对应的基础镜像里构建，或至少用 file 和 ldd（如果可用）双重确认。
- Distroless 镜像连
ldd都没有，file ./myapp是唯一快速验证手段 -
CGO_ENABLED=0不是万能解药：它会让部分功能退化（比如user.Lookup返回空用户名），需在业务逻辑中兜底 - CI 构建时建议加检查步骤：
file ./myapp | grep -q "statically linked" || exit 1
import "C"。 
