GOOS和GOARCH必须同时指定才能正确交叉编译；漏设任一变量将生成主机平台二进制，导致exec format error；arm与arm64不兼容，需用uname -m确认目标架构，并配合CGO_ENABLED=0确保纯Go静态链接。
GOOS和GOARCH必须同时指定
Go 编译跨平台二进制不是“默认支持 ARM”，而是靠 GOOS 和 GOARCH 两个环境变量协同生效。漏掉任一个，编译出来的还是当前主机的可执行文件。
-
GOOS=linux GOARCH=arm64 go build -o app-arm64 ./main.go—— 正确，生成 Linux ARM64 可执行文件 -
GOARCH=arm64 go build ...—— 错误，GOOS没设，默认仍是darwin或windows，结果是“无法执行：Exec format error” - 交叉编译不依赖本地 ARM 环境，但
CGO_ENABLED=0建议显式关闭，避免因 C 依赖导致失败
arm vs arm64 要分清，别混用
ARM 架构有多个子集，arm（32 位，如树莓派 Zero/1）和 arm64（64 位，如树莓派 3B+/4/5、AWS Graviton）完全不兼容。编译错目标，运行时直接报 exec format error，不是 panic，也不是链接错误，是内核拒绝加载。
- 查目标设备架构：
uname -m—— 输出aarch64对应arm64，armv7l对应arm - Go 支持的 ARM 选项只有
arm（对应 ARMv6+，软浮点）和arm64；没有armv7、armv8这类写法 -
arm下需额外指定GOARM=7（默认是 6），否则可能在较新设备上跑不动
CGO_ENABLED=0 是安全底线
开启 CGO 后，Go 会调用系统 C 库（如 glibc/musl），而宿主机和目标机的 C 库版本、ABI 往往不一致。一开 CGO，十有八九在目标机器上报 symbol not found 或直接段错误。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 纯 Go 程序（无
cgo调用、没 import "C"）—— 强烈建议加CGO_ENABLED=0 - 用了 SQLite、OpenSSL、图像处理等依赖 C 的库？要么换纯 Go 实现（如
mattn/go-sqlite3提供纯 Go 模式），要么自己搭 ARM 宿主机编译 -
CGO_ENABLED=0下不支持net包的某些 DNS 解析策略（如系统 resolv.conf fallback），如有需要得显式配置GODEBUG=netdns=go
验证和调试不能只看文件名
光看输出文件名或 file app 结果还不够。有些交叉编译产物看似是 ARM，实则动态链接了 x86 的 so，或者用了不兼容的 ELF 类型。
立即学习“go语言免费学习笔记（深入）”；
- 在目标机器上跑前，先用
file app确认：应显示ELF 64-bit LSB executable, ARM aarch64（arm64）或ELF 32-bit LSB executable, ARM（arm） - 用
readelf -h app | grep -E 'Class|Data|Machine'核对 ABI 细节 - 如果程序启动就挂，且
strace ./app显示execve返回-ENOEXEC，基本就是架构或 ABI 不匹配
真正麻烦的是混合了 cgo + 静态链接 + 自定义 sysroot 的场景——那已经不是 GOARCH 能解决的了，得切到目标平台真机或用 QEMU 模拟器编译。多数人卡住，其实都停在 GOOS/GOARCH 漏设或 arm/arm64 选错这一步。
