必须显式指定goos=linux和goarch=arm64（或arm）进行交叉编译，否则默认生成x86_64二进制无法在树莓派运行；推荐cgo_enabled=0静态编译以避免动态链接问题。
GOOS 和 GOARCH 必须显式指定为 linux/arm64 或 linux/arm
Go 编译树莓派程序不是“本地编译后拷过去就能跑”，关键在交叉编译环境配置。树莓派 4/5 默认用 arm64 架构（即使系统显示 aarch64），旧款 Pi 3B+ 及更早可能用 arm（需软浮点或硬浮点，推荐统一用 arm64 镜像）。不设 GOOS 和 GOARCH，go build 默认按宿主机生成二进制，x86_64 编出来的根本没法在 Pi 上执行。
- 树莓派 OS 64-bit（推荐）：
GOOS=linux GOARCH=arm64 go build -o myapp ./main.go - 树莓派 OS 32-bit（如 legacy Raspbian）：
GOOS=linux GOARCH=arm GOARM=7 go build -o myapp ./main.go（GOARM=7表示支持 VFPv3 浮点指令，Pi 2/3/4 均兼容） - 直接在 Pi 上编译？可以，但慢、耗资源；
go install或go build不加任何环境变量即可，前提是 Pi 上已装 Go（建议用官方二进制包而非 apt 源，后者版本太旧）
CGO_ENABLED=0 是避免动态链接失败的最简方案
默认开启 CGO 后，Go 会链接系统 C 库（如 libc、libpthread），而不同发行版的 libc 版本、路径甚至 ABI 可能不一致——尤其当你在 Ubuntu 宿主机交叉编译，目标却是 Debian-based 的树莓派 OS 时，运行时常报错：standard_init_linux.go:228: exec user process caused: no such file or directory（本质是动态链接器找不到）。
- 加
CGO_ENABLED=0强制纯静态编译：CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o myapp ./main.go - 这样生成的二进制不依赖外部共享库，拷过去就跑，体积略大但省心
- 若必须用 CGO（比如调用 SQLite、OpenSSL 或硬件驱动），就得确保宿主机和目标机的
sysroot一致，实际中几乎没人这么干——不如直接在 Pi 上编译
注意 /etc/os-release 和内核模块路径差异影响 runtime 行为
Go 程序本身不关心发行版，但你的代码如果读取 /etc/os-release、访问 /sys/class/gpio、调用 systemctl 或加载内核模块（如 dtoverlay 相关），就得留意树莓派 OS 的细节：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
/etc/os-release中VERSION_ID="12"（Bookworm）和"11"（Bullseye）会影响某些依赖 systemd 版本的逻辑判断 - GPIO 控制路径（如
/sys/class/gpio/export）在较新内核（6.1+）中已被libgpiod取代，直接写 sysfs 可能失败 - 交叉编译的二进制无法自动识别 Pi 的 CPU 温度传感器路径（
/sys/class/thermal/thermal_zone0/temp），需硬编码或运行时探测
构建产物体积与调试信息可按需裁剪
树莓派存储常受限（尤其 microSD 卡），发布前建议精简二进制：
- 去掉调试符号：
go build -ldflags="-s -w" -o myapp ./main.go（-s删除符号表，-w删除 DWARF 调试信息） - 启用 TinyGo？仅适用于无 goroutine、无反射、无 cgo 的极简场景；标准 Go 运行时在 Pi 上完全够用，别为省几 MB 引入兼容性问题
- 验证是否真为 arm64：
file myapp输出应含ARM64和statically linked（若用了CGO_ENABLED=0）
真正容易被忽略的是：交叉编译后的程序，os.Getwd()、exec.LookPath("ls") 这类行为仍取决于目标机环境，不是编译机。测试环节一定要在真实 Pi 上跑一遍，哪怕只 echo 一行日志。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
