GOOS和GOARCH必须严格匹配开发板真实平台，CGO_ENABLED=0是嵌入式部署硬性要求；需通过uname -m和uname -s确认目标架构与系统，禁用CGO确保静态链接，否则因缺失libc或动态链接器报Exec format error。
GOOS 和 GOARCH 必须匹配开发板的真实平台，否则生成的二进制文件无法运行；CGO_ENABLED=0 是多数嵌入式场景的硬性要求，否则会因缺失 libc 或动态链接器而报 Exec format error 或 cannot execute binary file。
确认开发板真实平台信息
别凭经验猜 —— 开发板标称“ARM”不等于 GOARCH=arm，更可能是 arm64（如 RK3399、全志 H6）或 arm + GOARM=7（如 i.MX6ULL）。实际平台需以开发板上运行的系统输出为准：
- 登录开发板，执行
uname -m：返回aarch64→ 对应GOARCH=arm64；返回armv7l→ 对应GOARCH=arm GOARM=7 - 执行
cat /proc/sys/kernel/ostype或uname -s确认GOOS：绝大多数嵌入式 Linux 板都是linux，极少数 RTOS 方案例外（不推荐用 Go） - 若开发板无 shell 访问能力，查 BSP 文档中的 kernel config：
CONFIG_ARM64=y或CONFIG_ARM=y+CONFIG_ARMV7=y
本地交叉编译命令必须禁用 CGO
开发板通常无完整 libc、无动态链接器（/lib/ld-musl-* 或 /lib64/ld-linux-x86-64.so.2），一旦启用 cgo，go build 会生成动态链接二进制，直接失败。
- 强制静态编译：始终前置
CGO_ENABLED=0，例如CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app-arm64 main.go - 即使项目没显式 import
"C"，某些标准库（如net）在 CGO 启用时也会调用系统 DNS 解析，导致隐式依赖；关闭后自动回退到纯 Go 实现（如net/lookup.go） - 验证是否真为静态：在宿主机上运行
file app-arm64，输出含statically linked才安全；若含dynamically linked，说明CGO_ENABLED没生效（常见于 shell 函数封装漏传环境变量）
Docker 构建镜像时注意 Alpine 与 glibc 兼容性
用 golang:alpine 镜像交叉编译看似轻量，但 Alpine 默认用 musl libc，而部分开发板运行的是 glibc（如某些 Yocto 构建的镜像），此时 CGO_ENABLED=0 可绕过，但若你必须启用 cgo（例如调用硬件驱动 ioctl），musl 编译出的二进制在 glibc 系统上大概率崩溃。
- 优先选官方
golang:1.22-slim（基于 Debian，含 glibc）作为 builder 基础镜像，避免 libc 不匹配 - 若坚持用 Alpine，且目标板也是 Alpine 系统，需确保
apk add musl-dev已安装 —— 否则CGO_ENABLED=1会报gcc: command not found - Docker 多阶段构建中，final 阶段不要盲目 COPY
--from=builder的二进制到alpine:latest：只要CGO_ENABLED=0，最终镜像甚至可用scratch（真正零依赖）
部署前务必验证目标平台可执行性
交叉编译完成不等于能跑通。开发板资源有限，常见陷阱不是语法错，而是运行时行为偏差：
立即学习“go语言免费学习笔记（深入）”；
- 用
scp传上去后先运行./app-arm64 --help或加-v参数，看是否立即 panic 或卡住 —— 这往往意味着 syscall 兼容问题（如旧内核不支持membarrier） - 若程序依赖定时器、网络或文件系统，需确认开发板内核配置已开启对应选项（如
CONFIG_POSIX_TIMERS=y、CONFIG_NET=y） - 日志输出别依赖
systemd-journald：嵌入式系统常无此服务，改用log.SetOutput(os.Stdout)并重定向到串口或文件
time.Now() 在某些低功耗嵌入式内核上可能返回零值或跳变，这不是编译问题，而是内核 clocksource 配置不当；遇到时间异常，优先检查 dmesg | grep clocksource 而非重编译。 
