Go原生支持跨平台编译，但必须同时正确设置GOOS和GOARCH且配对有效，缺一或错一则生成本地二进制；CGO_ENABLED=0是多数场景安全默认，启用CGO需配齐目标平台C工具链。
Go 原生支持跨平台编译，但直接跑 go build 很大概率生成的是你当前机器的二进制——不是目标平台的。关键不在“能不能”，而在“怎么设对环境变量”和“要不要关 CGO”。
GOOS 和 GOARCH 必须同时设置且配对有效
单独设 GOOS=linux 或只改 GOARCH=arm64 都没用，go build 会退回到本地平台。漏设、拼错、大小写不一致（比如写成 goos）都会导致静默失败。
-
GOOS=windows GOARCH=amd64→ 正确，生成 PE 格式可执行文件 -
GOOS=darwin GOARCH=arm64→ 正确，适配 Apple Silicon -
GOOS=linux GOARCH=386→ 正确，x86 32 位 Linux（注意不是i386） -
GOOS=Linux GOARCH=amd64→ 错误，Linux大写，无效值，编译出本地文件 -
GOOS=windows（缺GOARCH）→ 编译出main.exe，但架构是当前机器的（比如 macOS 上生成的是 darwin+arm64 的 exe，根本不能运行）
验证是否生效：用 file ./myapp 查看输出，Linux 文件应显示 “ELF 64-bit LSB executable”，Windows 应是 “PE32+ executable (console) x86-64”，不匹配就说明环境变量没起作用。
CGO_ENABLED=0 是多数场景下的安全默认
只要你的代码没显式调用 C（没写 import "C"，没用 os/user.User.Lookup 或某些 net.InterfaceAddrs 变体），关掉 CGO 就能避免 libc 版本、头文件缺失、交叉链接器找不到等一堆问题。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- macOS 上编译 Linux 二进制，忘了加
CGO_ENABLED=0→ 可能静默生成 darwin 二进制，或报cannot use cgo when CGO_ENABLED=0（矛盾提示，本质是 CGO 状态混乱） - Linux 主机编译 Windows 版本，
CGO_ENABLED=1→ 报错找不到gcc或windres，因为没装 MinGW 工具链 - 用了
net包且 CGO 开启时，不同平台 DNS 解析行为可能不一致，上线后偶发连接失败
稳妥做法：所有交叉编译命令开头都加 CGO_ENABLED=0，除非你明确需要 C 互操作，并已配好对应平台的完整交叉工具链。
Windows 目标自动加 .exe 后缀，别硬编码路径
GOOS=windows 时，go build -o dist/app 实际生成的是 dist/app.exe；而 GOOS=linux 下就是 dist/app。这个行为由 cmd/go 内部控制，无法禁用。
- CI 脚本里写死
-o bin/myapp→ 在 Windows 构建任务中，实际产物是bin/myapp.exe，但后续上传逻辑若按bin/myapp找文件就会失败 - 用
file检查发现 Linux 机器上有个 “PE32+ executable” → 八成是误把 Windows 二进制当 Linux 放进容器，启动时报exec format error - 脚本中动态拼接输出名更可靠：
OUTPUT_NAME="myapp-$GOOS-$GOARCH"; [ "$GOOS" = "windows" ] && OUTPUT_NAME="$OUTPUT_NAME.exe"
别依赖 IDE 或 shell 补全去猜后缀，GOOS 值才是唯一权威来源。
ARM 架构要特别注意指令集兼容性
GOARCH=arm 和 GOARCH=arm64 完全不同：arm 默认生成 ARMv6 指令（树莓派 Zero/1），而现代 ARM64 服务器（如 AWS Graviton、Mac M1/M2、树莓派 4/5）只能运行 arm64 二进制。
- 在 macOS M1 上跑
GOOS=darwin GOARCH=amd64→ 生成的二进制只能在 Intel Mac 运行，M1 上执行报Bad CPU type in executable - 在 x86_64 Linux 上编译
GOOS=linux GOARCH=arm→ 生成的 ELF 文件在 aarch64 内核上运行会报not a valid ELF - 不确定目标设备架构？先用
uname -m或arch确认，再选arm64（优先）或arm（仅旧设备）
最易被忽略的一点：交叉编译不能替代真机测试。生成的二进制即使 file 显示正确，也可能因系统调用差异、权限模型、路径约定等问题在目标环境崩溃——尤其是涉及 os/exec、syscall 或信号处理时。
