交叉编译需设GOOS和GOARCH并禁用CGO：GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -ldflags="-s -w" -o main main.go，确保静态链接且兼容目标架构。
交叉编译前必须设置 GOOS 和 GOARCH
Go 默认编译当前主机平台的可执行文件，直接在 x86_64 Linux 上运行 go build 会生成 x86_64 二进制，无法在 ARM 或 MIPS 架构的嵌入式设备上运行。必须显式指定目标环境：
-
GOOS=linux：目标操作系统固定为 linux（不能省略，即使目标也是 Linux） -
GOARCH=arm64：常见嵌入式架构，如树莓派 4、RK3399 等；若用旧设备，可能是arm（需额外设GOARM=7） - 其他常用组合：
GOARCH=mips64le（用于某些国产 SoC）、GOARCH=arm+GOARM=6（兼容性更强但性能略低）
错误示例：GOOS=linux go build main.go —— 缺少 GOARCH，仍会生成本地架构二进制。
静态链接是嵌入式部署的关键前提
嵌入式 Linux 系统通常精简，缺少 glibc 或动态库路径不全，而 Go 默认启用 CGO（调用 C 库），会导致生成动态链接可执行文件，运行时报错：./main: not found 或 no such file or directory（实际是找不到 ld-linux-arm64.so.1 等解释器）。
- 禁用 CGO：
CGO_ENABLED=0 go build -o main main.go - 确保静态链接生效：用
file main检查输出中是否含statically linked；若出现dynamically linked，说明 CGO 未关或被间接启用（比如用了os/user、net等依赖 cgo 的包） - 若必须用 net 包（如 HTTP 客户端），可通过构建 tag 或替换 DNS 解析方式规避 cgo，例如加
-tags netgo强制使用 Go 原生 DNS 解析
交叉编译时要注意标准库和第三方包的兼容性
不是所有 Go 代码都能无修改交叉编译成功。常见问题集中在：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
syscall相关调用：部分函数在目标架构上未实现（如syscall.Reboot在 arm64 上不可用），编译报错undefined: syscall.Reboot - C 语言头文件依赖：如果项目启用了 CGO 并引用了
<sys/ioctl.h>等，需提供对应架构的 sysroot 和头文件，复杂度陡增，应优先避免 - 第三方包隐式依赖 cgo：比如
github.com/mattn/go-sqlite3默认启用 cgo，需改用-tags sqlite_nomysql或彻底换用纯 Go 的 SQLite 实现（如modernc.org/sqlite） - 构建命令建议组合：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -ldflags="-s -w" -o main main.go，其中-s -w去除符号表和调试信息，减小体积
验证和调试要回到目标板上做最小闭环
交叉编译成功不等于能跑通。嵌入式环境资源受限，容易暴露新问题：
- 权限问题：
chmod +x main后仍提示Permission denied？检查文件系统是否挂载为noexec，或改用./main显式调用（避免 shell 解释器限制） - 栈空间不足：ARM 设备默认栈较小，Go 程序启动即 panic
runtime: goroutine stack exceeds 1000000000-byte limit，可在main()开头加debug.SetMaxStack(32 * 1024 * 1024)临时缓解 - 日志输出卡住：标准输出未刷新，加
log.SetOutput(os.Stdout)和log.Println("start")后手动os.Stdout.Sync()确保可见 - 最简验证法：先写一个只打印
"hello"并 sleep 5 秒的程序，确认能编译、传输、执行、退出，再逐步叠加功能
真正麻烦的往往不是编译本身，而是跨架构后浮点精度差异、系统调用行为偏移、或内核版本太老导致某些 syscall 号无效——这些只能在目标板上复现和定位。
