GOOS和GOARCH必须同时显式设置，仅设GOOS=linux会导致生成与目标服务器架构不匹配的二进制而无法运行；CGO_ENABLED=0是默认安全前提，否则会因动态链接宿主机C库导致Linux上运行失败。
GOOS 和 GOARCH 必须同时显式设置
只设 GOOS=linux 不设 GOARCH，Go 会沿用你当前机器的架构（比如 macOS M1 上默认是 arm64），结果生成的是 linux/arm64 —— 但你要部署到 x86_64 服务器上，它根本跑不起来。go build 不会“猜”目标平台，漏一个变量就等于编译错目标。
正确做法永远是用 env 前置一次性指定：
env GOOS=linux GOARCH=amd64 go build -o myapp-linux .
别用 export 全局设置再跑 go build，容易污染后续命令；也别信 CI 脚本里残留的旧值，每次检查用：go env GOOS GOARCH
CGO_ENABLED=0 不是可选项，而是默认安全前提
只要你的代码没 import "C"，也没依赖 SQLite、libgit2、OpenSSL 等必须 cgo 的第三方库，就必须关 CGO。否则 Go 会尝试链接你本地的 C 库（比如 macOS 的 libSystem 或 Ubuntu 的 glibc），而目标平台根本没有这些动态库，运行时直接崩溃或报 cannot execute binary file: Exec format error。
立即学习“go语言免费学习笔记（深入）”；
检查是否含 cgo 文件：
go list -f '{{.CgoFiles}}' ./
返回非空切片（如 [main.c]）说明有 cgo；返回 [] 就可以放心加 CGO_ENABLED=0：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o app.exe .
关 CGO 后，net 包 DNS 解析会 fallback 到 Go 自实现（读 /etc/resolv.conf），os/user 可能返回空或 panic —— 这不是 bug，是纯 Go 实现的已知行为。
build constraints exclude all Go files 是最隐蔽的失败信号
这个错误不是编译器坏了，是 Go 扫完所有 .go 文件，发现每个都被构建约束跳过了。典型场景：
- 某个文件顶部写了
// +build windows，但你在GOOS=linux下构建，该文件被排除 - 其他文件也类似，比如
_linux.go、_darwin.go都带平台标签，而公共接口文件没加任何// +build，导致它被所有平台编译——但又调用了平台限定函数（如syscall.Kill），实际无法通过类型检查
解决方法：确认主逻辑文件没有构建约束；平台特化代码用 _linux.go、_windows.go 命名，且确保至少有一个平台能匹配并编译成功；用 go list -f '{{.GoFiles}}' -tags linux ./ 模拟某平台视角看哪些文件会被纳入。
验证二进制是否真可用，不能只看文件名
GOOS=windows 时 go build -o app 会自动生成 app.exe，但文件名对不上不代表它真的能在 Windows 上跑。验证必须分两步：
第一步看格式：file app.exe 应输出 PE32+ executable (console) x86-64；file myapp-linux 应输出 ELF 64-bit LSB executable, x86-64。
第二步看链接：ldd myapp-linux 在 Linux 上应显示 not a dynamic executable（静态链接）；若出现一堆 libc.so.6 => not found，说明 CGO 没关干净或用了 musl/glibc 混淆。
Windows 上没法用 ldd，但可在 WSL 里用 objdump -x app.exe | grep DLL 查是否有外部 DLL 依赖——有就是没静态链接成功。
