GOOS和GOARCH必须同时设置，缺一不可；仅设GOOS会导致沿用本机架构而引发exec format error，且build constraints可能因GOARCH未指定而匹配失败。
GOOS和GOARCH必须同时设置，缺一不可
只设 GOOS=linux 而不指定 GOARCH，Go 会沿用你本机的架构（比如 M1 Mac 默认是 arm64），但目标服务器可能是 amd64——编译出来的二进制扔过去直接报 cannot execute binary file: exec format error。
常见错误现象 build constraints exclude all Go files，本质是构建标签（如 // +build linux）匹配失败，因为 Go 拿你没设的 GOARCH 去比对，结果找不到满足条件的文件。
- Mac 编译 Linux amd64：必须写
GOOS=linux GOARCH=amd64，不能省略任一 - Windows 编译 macOS arm64：必须写
GOOS=darwin GOARCH=arm64，且GOOS=windows会自动加.exe后缀，其他平台不会 - PowerShell 用户别用
$env:GOOS="linux"单独赋值——后续go build不会自动读取，得用env GOOS=linux GOARCH=arm64 go build -o app这种一次性方式
CGO_ENABLED=0 是静态链接和跨平台稳定运行的前提
只要你的 Gin 项目没显式 import "C"、没用 github.com/mattn/go-sqlite3 或 net 包里触发 CGO 的部分（如 DNS 解析默认走 cgo），就该默认关掉 CGO。否则生成的二进制依赖目标机的 libc，在 Alpine 容器或嵌入式 Linux 上运行会报 standard_init_linux.go:228: exec user process caused: no such file or directory。
-
CGO_ENABLED=0后，net包会回退到纯 Go 实现（如纯 Go DNS 解析），性能略有下降但可移植性拉满 - Windows 上编译 Linux 二进制时报
exec: "gcc": executable file not found，根本原因就是CGO_ENABLED=1却没装交叉 C 工具链，直接关掉最省事 - Gin 本身不依赖 CGO，但如果你用了
sqlite3、openssl、zlib等带 C 绑定的中间件，就得要么换纯 Go 替代（如github.com/ziutek/mymysql），要么接受构建环境复杂化
Windows PowerShell 下编译命令容易漏掉 env 包裹
PowerShell 对环境变量作用域控制严格，$env:GOOS="linux" 只影响当前 session 的后续命令，但 go build 启动子进程时不一定继承——尤其当你用 IDE 或脚本调用时，常出现“变量设了却没生效”的情况。
立即学习“go语言免费学习笔记（深入）”；
- 推荐统一用
env GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o myapp-linux ./cmd/myapp - 如果坚持用 PowerShell 变量赋值，必须在同一行执行：
$env:GOOS="linux"; $env:GOARCH="amd64"; $env:CGO_ENABLED="0"; go build -o myapp-linux ./cmd/myapp - 检查是否生效：在
go build前加go env | findstr -i "goos|goarch|cgo"（CMD）或go env | Select-String -Pattern "GOOS|GOARCH|CGO"（PowerShell）
Mac 上编译 Windows 二进制需注意路径分隔符和 GUI 隐藏
Go 编译出的 Windows 二进制在 Mac 上无法运行，但能生成；真正要注意的是运行时行为差异，比如文件路径用 还是 /、控制台窗口是否弹出。
- 路径处理一律用
path/filepath，别硬写"C:\foo\bar"或"C:/foo/bar" - 编译 Windows GUI 程序（无黑框）：加
-ldflags="-H windowsgui"，否则双击 exe 会闪退 - Gin 默认监听
:8080，Windows 防火墙可能拦截，上线前建议改用非特权端口或明确绑定127.0.0.1:8080
-ldflags="-H windowsgui" 同时把日志重定向到文件，要么干脆不启用 GUI 模式，用命令行方式运行。 
