Go原生编译器无法用于嵌入式开发，必须使用TinyGo；它基于LLVM重写，专为裸机设计，需强制指定-target参数，依赖machine包安全操作硬件，且time.Sleep、channel等行为受限。
Go 原生编译器不能用于嵌入式开发，必须用 TinyGo；它不是“Go 的轻量版”，而是从 LLVM 重写的、面向裸机的替代编译器。
tinygo build -target=xxx 是硬性要求，不指定就编译失败
标准 go build 会尝试链接 runtime/cgo 和操作系统调用，裸机根本没有这些——直接报错 cannot load runtime/cgo: no buildable Go source files 或链接段缺失。TinyGo 不同，它靠 -target 决定一切：启动代码、寄存器定义、时钟初始化逻辑、甚至 machine.LED 映射到哪根物理引脚。
- 选错 target（比如把
raspberry-pi-pico写成pico）会导致 UART 不出字、LED 不响应、烧录后板子无反应 - 常见 target 名要查官方 targets/ 目录，例如 ESP32-C3 是
esp32-c3-devkit，Arduino Nano 33 是arduino-nano33 -
tinygo flash隐含调用build+ 烧录命令，但调试阶段建议先用tinygo build -target=xxx -o firmware.hex ./main.go确认能生成二进制
machine 包是唯一安全操作硬件的方式，别碰裸地址
TinyGo 的 machine 包不是封装层，它是芯片级抽象：自动处理时钟使能、APB/AHB 总线配置、引脚复用（MUX）、寄存器位宽对齐。手写 *(*uint32)(0x40001000) 看似灵活，实则跨芯片失效、优化后行为不可控、且极易因寄存器偏移错位导致外设静默。
- 初始化 UART 必须先调
machine.UART0.Configure()，否则fmt.Printf什么也不输出（即使编译通过） - LED 控制前必须
machine.LED.Configure(machine.PinConfig{Mode: machine.PinOutput})，否则.High()只是改了个无效寄存器 - 查引脚定义永远优先看
machine.PA05、machine.BUTTON这类常量，而不是翻数据手册找 GPIOA_BSRR
time.Sleep 和 channel 在 TinyGo 中行为受限，不能按标准 Go 理解
TinyGo 没有抢占式调度器，time.Sleep 底层依赖 SysTick 或其他定时器中断；channel 是编译期固定大小的环形缓冲，RAM 占用在链接时就确定了——这对 RAM 仅 32KB 的 SAMD21 或 ESP32-C3 是致命约束。
立即学习“go语言免费学习笔记（深入）”；
-
time.Sleep(1 * time.Second)若中断被禁用或 SysTick 频率未正确配置，程序会卡死在循环里，毫无提示 - 无缓冲
chan int只能用于同步握手，不能传数据；带缓冲通道容量必须是常量，如make(chan int, 4)，不能是变量 -
select语句不支持发送分支阻塞等待（case ch ），只支持接收和 <code>default，否则编译报错
fmt.Printf 默认不可用，UART 输出需主动启用且易丢字
TinyGo 默认禁用所有 fmt 输出函数——因为它们依赖底层 writer 接口，而裸机没有 os.Stdout。即使你手动重定向到 machine.UART0，波特率错、缓冲区溢出、中断未开都会导致乱码或卡死。
- 启用前必须确保：
machine.UART0.Configure(machine.UARTConfig{BaudRate: 115200}) - 避免在中断服务程序（ISR）中调用
fmt.Printf，它可能触发内存分配或阻塞 - 调试优先用 LED 闪烁编码（如摩尔斯码式闪灯），比依赖串口更可靠；UART 仅作辅助验证
真正麻烦的不是语法，是每个 machine.XXX.Configure() 调用背后隐藏的芯片手册细节：时钟树怎么开、哪个寄存器控制复位释放、引脚复用模式是否冲突——这些不会报错，只会让功能静默失效。查 targets/ 下对应 JSON 文件和芯片参考手册，比猜更快。
