在 macos 或 windows 上编译 linux 可执行文件需显式设置 goos=linux 和 goarch，若启用 cgo 则需配置交叉编译工具链或禁用 cgo；推荐使用 docker 构建以规避环境差异。
Go 编译 Linux 可执行文件，直接设 GOOS 和 GOARCH
Go 默认按当前系统编译，想在 macOS 或 Windows 上生成 Linux 程序，不能只靠 go build，必须显式指定目标平台。不设 GOOS=linux，编译出来的是你本地系统的二进制，扔到 Linux 上直接报 cannot execute binary file: Exec format error。
实操建议：
- 在终端里先临时设置环境变量：
GOOS=linux GOARCH=amd64 go build -o myapp main.go - 交叉编译 ARM64 Linux（比如跑在树莓派或云服务器上）：用
GOARCH=arm64，不是arm或aarch64 - 如果项目用了 cgo（比如调了 SQLite、OpenSSL），默认会失败——Linux 的 C 标准库头文件和链接器在 macOS/Windows 上不存在
cgo 开启时编译 Linux 程序，得配好交叉编译工具链
只要代码里有 #import "C" 或依赖含 cgo 的包（如 database/sql 配 _ "github.com/mattn/go-sqlite3"），GOOS=linux 就不够用了。这时候 Go 会尝试调用 gcc，但宿主机的 gcc 不认识 sys/stat.h 这类 Linux 头文件。
实操建议：
- 禁用 cgo 是最简方案：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o myapp main.go - 启用 cgo 时，macOS 上需装
x86_64-linux-gnu-gcc（用 Homebrew：brew install x86_64-linux-gnu-binutils x86_64-linux-gnu-gcc），再设CC_x86_64_linux_gnu=x86_64-linux-gnu-gcc - Windows 用户基本别硬刚 cgo 交叉编译，Docker 更稳：
docker run --rm -v $(pwd):/src -w /src golang:1.22-alpine go build -o myapp main.go
Linux 上运行失败？检查 libc 版本和静态链接
即使成功编译出 Linux 二进制，放到旧版 CentOS 7 或 Alpine 容器里可能报 version `GLIBC_2.34' not found。这是因为 Go 默认动态链接宿主机的 libc（如果你在 Ubuntu 22.04 编译，它用的是较新 glibc）。
实操建议：
-
CGO_ENABLED=0编译出来的二进制是纯静态的，自带 runtime，能跑在任意 Linux 内核 + 最小用户空间（包括 Alpine） - 启用 cgo 后想静态链接？加
-ldflags '-extldflags "-static"'，但部分库（如 OpenSSL）仍可能动态依赖，不保证 100% 静态 - 用
file myapp看输出是否含statically linked；用ldd myapp确认有没有动态依赖（在 Linux 上执行）
为什么 Docker 构建更可靠？它绕过了本地环境差异
本地交叉编译容易卡在 cgo、libc、环境变量顺序、shell 类型（zsh/bash）这些细节上。而 golang:alpine 或 golang:slim 镜像本身就在 Linux 环境里，go build 走的是原生路径，没跨平台转换开销。
实操建议：
- 最小可行命令：
docker run --rm -v $(pwd):/work -w /work golang:1.22-alpine go build -o myapp-linux main.go - 想保留调试信息？去掉
-ldflags '-s -w'；想减体积？加进去 - CI/CD 中优先用 Docker 方式，避免开发机和构建机环境不一致导致“我本地好好的”问题
真正麻烦的从来不是 GOOS=linux 这一行，而是 cgo、libc、DNS 解析（netgo 标签）、甚至 GOPROXY 在内网的可用性。每次换环境，先跑 go env | grep -E 'GOOS|GOARCH|CGO' 确认当前上下文，比猜强得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
