交叉编译前必须显式设置goos和goarch，二者缺一不可；仅设其一将生成当前平台二进制，导致运行时报exec format error；cgo_enabled=0是稳定交叉编译的默认安全开关。
交叉编译前必须显式设置 GOOS 和 GOARCH
Go 的交叉编译不依赖外部工具链，但默认只编译当前系统平台。漏设或拼错 GOOS/GOARCH 是新手最常遇到的失败原因——编译能成功，但生成的二进制在目标机器上直接报 cannot execute binary file: Exec format error。
常见组合要记牢：GOOS=linux + GOARCH=amd64（主流服务器），GOOS=windows + GOARCH=386（32 位 Windows），GOOS=darwin + GOARCH=arm64（M1/M2 Mac）。注意 darwin 不支持 386，windows 不支持 arm64（Go 1.21+ 才开始实验性支持）。
实操建议：
- 始终用
env GOOS=xxx GOARCH=yyy go build -o xxx形式，避免污染当前 shell 环境 - 检查支持列表：运行
go tool dist list，输出含所有合法组合，别凭经验硬写 - 若用
CGO_ENABLED=1，交叉编译基本失效（需对应平台的 C 工具链），学习阶段一律设为0
写可复用的跨平台构建脚本要避开 runtime.GOOS 陷阱
脚本里如果用 Go 代码读取 runtime.GOOS 或 runtime.GOARCH，拿到的是构建机的值，不是目标平台。这意味着你用 Linux 写的构建脚本，即使设置了 GOOS=windows，脚本内部仍会误判为 linux。
正确做法是把目标平台作为参数传入，或从环境变量提取。比如 Bash 脚本中：
#!/bin/bash
TARGET_OS=${1:-linux}
TARGET_ARCH=${2:-amd64}
env GOOS=$TARGET_OS GOARCH=$TARGET_ARCH CGO_ENABLED=0 go build -o myapp-$TARGET_OS-$TARGET_ARCH .
这样调用 ./build.sh windows amd64 就生成 myapp-windows-amd64.exe。别试图在 Go 代码里做平台分支逻辑来“适配”不同目标——那属于运行时行为，和交叉编译无关。
go build -ldflags 对跨平台二进制的影响不可忽略
加 -ldflags 很常见，比如嵌入版本号：-ldflags="-X main.Version=1.2.3"。但它在交叉编译下有个隐蔽问题：若链接时用了绝对路径（如 -ldflags="-extld /usr/bin/x86_64-linux-gnu-gcc"），而该路径在构建机上不存在，就会失败。
更关键的是，某些标志会影响平台兼容性：
-
-ldflags="-s -w"（去符号表和调试信息）对所有平台都安全，推荐加上以减小体积 -
-ldflags="-H windowsgui"只对GOOS=windows有效，其他平台会静默忽略，但别滥用——它会让控制台程序不弹黑窗，也意味着你收不到fmt.Println输出 - 避免
-ldflags="-linkmode external"，它强制走外部链接器，在多数交叉场景下不可用
多系统部署时，静态链接和依赖路径是两道坎
Go 默认静态链接，所以大多数情况下生成的二进制扔到目标系统就能跑。但有两个例外必须处理：
-
CGO_ENABLED=1时（比如用了net包的 DNS 解析），会动态链接libc，Linux 上要求目标机器有对应版本的glibc；解决方案是改用musl（如 Alpine 镜像）或切回CGO_ENABLED=0（DNS 降级为纯 Go 实现） - 硬编码的配置路径、日志目录如果写成
/etc/myapp/或C:\Program Files\...，在其他系统上必然失败；应统一用os.UserConfigDir()或filepath.Join(os.Getenv("HOME"), ".myapp")
真正麻烦的不是编译，而是让一个二进制在 Linux/macOS/Windows 上都用同一套路径逻辑、同一套配置加载方式——这需要设计时就放弃“按 OS 写死路径”的惯性思维。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
