结论是：esp32必须用tinygo而非标准go编译器，因其精简运行时（无gc、反射、完整net/http）适配资源限制，生成100–300kb固件；树莓派则需关闭cgo交叉编译为linux arm二进制。
直接说结论：别用标准 Go 编译器往 ESP32、Arduino 或树莓派 GPIO 上硬跑，go build 出来的二进制根本塞不进 Flash，也扛不住内存限制——得按硬件类型选对工具链。
ESP32 项目必须用 TinyGo，不是“可以”，是“只能”
标准 Go 运行时在 ESP32 上无法启动，runtime.init 就会 panic；TinyGo 删掉了 GC、反射和大部分 net/http，但保留了 goroutine 和 channel 的语义。它生成的固件体积通常控制在 100–300KB，刚好 fit 进 ESP32-WROOM-32 的 4MB Flash。
- 安装后验证：
tinygo version必须显示tinygo version 0.30.0或更高（低于 0.29 不支持 ESP32-S3 USB CDC） - 编译命令不是
go build，而是：tinygo build -o firmware.hex -target=esp32 ./main.go -
machine.UART0、machine.LED这类引脚操作只在 TinyGo 的machine包里存在，标准 Go 没有这个包 - 别试图导入
encoding/json大量数据解析——TinyGo 默认禁用 float64，json.Unmarshal会 silently 失败，改用encoding/json的 subset 或手写解析
树莓派/ARM Linux 网关用标准 Go，但得关掉 CGO
树莓派 4B 或 RK3506 这类带完整 Linux 的工业网关，可以用标准 Go 编译器，但默认开启 CGO_ENABLED=1 会链接 libc，导致交叉编译失败或运行时报 cannot execute binary file: Exec format error。
- 交叉编译前务必设置：
CGO_ENABLED=0 GOOS=linux GOARCH=armv7 go build -o collector ./cmd/collector - GPIO 控制不能靠
os/exec调gpio命令——太慢且不可靠；要用periph.io/x/periph库直接 mmap /dev/gpiomem，它比 sysfs 接口快 10 倍以上 -
periph初始化必须加host.Init()，否则gpio.PinOut配置会 panic，这个调用容易被文档漏掉 - Modbus RTU 串口通信慎用
github.com/tbrandon/mb——它依赖syscall在 ARM 上不稳定；推荐用github.com/wagoodman/go-partybus+ 手动帧组装
Gobot 框架只适合原型验证，别上生产环境
gobot.io/x/gobot/v2 写 demo 很快，但它的 robot.Start() 是阻塞式主循环，没有错误恢复机制，也没有 graceful shutdown 支持。一个 driver 初始化失败，整个 robot 就卡死。
- 真实设备部署时，
robot.Start()应该包装成context.WithTimeout，否则看门狗无法介入 - 它的
Adaptor对树莓派 5 的 BCM2712 SoC 支持不全，raspberrypi.NewAdaptor()会误读 GPIO 27 的电平状态 - 并发模型是单 goroutine 轮询，
Every(100*time.Millisecond, ...)实际间隔可能漂移到 150ms+，不适合毫秒级传感器同步 - 真正要量产，得拆开 Gobot 的
Driver层，把Read()和Write()提出来，自己用time.Ticker+select控制节奏
最常被忽略的一点：所有面向硬件的 Go 项目，init() 函数里绝不能做耗时操作。TinyGo 的 init 在 Flash 加载后立即执行，没机会等外设就绪；标准 Go 的 init 在 main 前运行，但 periph 的 host.Init() 必须显式调用——这两者混用，会导致引脚配置失效却无任何报错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
