OpenWRT交叉编译需严格匹配GOARCH与GOARM：MIPS设备用mipsle，ARMv7用arm+GOARM=7，aarch64用arm64；必须设CGO_ENABLED=0避免libc依赖问题，并清空GO386等干扰环境变量。
Go 交叉编译目标平台选错，GOARCH 和 GOARM 怎么配？
OpenWRT 常见的 MIPS（如 mt7621）和 ARM（如 ipq4019、bcm2711）设备，不能直接用本地 amd64 的 Go 编译结果。关键不是“能不能编”，而是“编出来的二进制会不会启动就 segmentation fault 或 exec format error”。
-
GOARCH必须严格匹配 CPU 指令集：MIPS 设备用mips（小端）或mipsle（小端，更常见），ARM 设备看内核输出uname -m——armv7l对应arm，aarch64对应arm64 - ARM 下必须显式设
GOARM=7（多数 OpenWRT ARMv7 设备不支持 v8 指令，设成 8 会 panic） - MIPS 设备注意软浮点/硬浮点：OpenWRT 默认用
softfloat，Go 编译时要加-ldflags="-linkmode external -extldflags '-mfloat-abi=soft'"，否则运行时报Illegal instruction
为什么 CGO_ENABLED=0 几乎是必须的？
嵌入式设备上几乎没有标准 C 库的完整实现，libc 版本、libpthread 存在与否、符号导出方式都不可控。一旦开启 CGO，Go 会链接宿主机的 glibc 或 musl，导致运行时报 not found 或直接 abort。
- 默认开启 CGO 时，
net包会调用getaddrinfo等系统函数，而 OpenWRT 的musl可能缺实现或行为不一致 - 强制设
CGO_ENABLED=0后，Go 自带纯 Go 的 DNS 解析和网络栈，体积略大但稳定得多 - 如果真要用 CGO（比如调用硬件驱动 ioctl），必须用 OpenWRT SDK 提供的
staging_dir下的工具链和 sysroot，不能靠本地gcc
GOOS=linux 是对的，但别漏掉 GO386=sse2 这类隐性陷阱
虽然你没在编译 x86 程序，但 Go 工具链内部可能因环境变量残留启用某些指令集优化。尤其在 macOS 或较新 Linux 宿主机上交叉编译旧设备程序时，GO386=sse2 会被自动注入，而老式 MIPS/ARM 设备根本没 SSE 单元 —— 结果就是程序一运行就 Illegal instruction。
- 编译前务必清空无关环境变量：
env -i GOOS=linux GOARCH=mipsle GOARM=7 CGO_ENABLED=0 go build -o myapp . - 验证生成文件架构：
file myapp应显示MIPSLE executable或ARM aarch64，而非x86-64 - 若用 Makefile 或 CI 脚本，注意 shell 环境继承问题 —— 不要只 export 部分变量，建议用
env -i显式控制
OpenWRT 上跑不起来？先检查 /lib/ld-musl-*.so.1 是否存在
Go 静态链接后一般不依赖外部 ld，但如果你开了 CGO 或用了某些特殊构建标记，仍可能动态链接 musl。而 OpenWRT 的 libc 路径不固定，常见于 /lib/ld-musl-mipsle.so.1（MIPS 小端）或 /lib/ld-musl-armv7.so.1（ARMv7），名字和实际路径稍有偏差就会报 No such file or directory。
- 用
readelf -l myapp | grep interpreter查看程序期望的动态链接器路径 - 在目标设备上执行
ls /lib/ld-musl-*，对比是否匹配；不匹配就只能重编译或用patchelf改（不推荐，易出错） - 最稳方案仍是
CGO_ENABLED=0+ 默认构建，此时readelf输出里 interpreter 字段为空，表示静态链接
最容易被忽略的是：OpenWRT 的 libc 是按 CPU sub-architecture 打包的，比如 mips_24kc 和 mips_mips32 的 ld-musl 文件名不同，而 Go 不会自动适配 —— 它只认你指定的 GOARCH，不感知 sub-arch。所以设备型号和 SDK profile 必须严格对应。
