TinyGo 的 machine.Sleep() 提供三种硬件休眠模式：IDLE（CPU停、外设全开，唤醒快但功耗1–5mA）、DEEPSLEEP（仅RTC和唤醒引脚供电，功耗10–100µA，需重初始化外设）、STANDBY（功耗最低）。
Go 本身不直接控制硬件睡眠与唤醒，必须通过 TinyGo 或嵌入式 runtime 配合底层寄存器操作；纯标准 Go（golang.org/dl/go1.25）在 Linux/macOS/Windows 上无法让设备真正进入深度睡眠并由外部事件唤醒。
用 TinyGo 实现空闲/深度睡眠：Sleep() 函数的三种模式怎么选
标准 Go 的 time.Sleep 只是协程挂起，CPU 仍在运行；真正省电得靠 TinyGo 提供的 machine.Sleep()，它会触发 MCU 硬件级休眠：
-
machine.IDLE：CPU 停，外设（UART、I²C、ADC）全开，适合等待传感器中断或串口数据——唤醒快（微秒级），但功耗仍约 1–5 mA -
machine.DEEPSLEEP：关掉大部分时钟域，仅 RTC 和唤醒引脚供电，电流可压到 10–100 µA；但唤醒后需重初始化外设，不能保留 GPIO 状态 -
machine.STANDBY：功耗最低（
常见错误：在 DEEPSLEEP 模式下还依赖未保存的全局变量，结果唤醒后值全为零；正确做法是把关键状态写进 RTC 备份寄存器或 EEPROM。
唤醒源配置：为什么写了 Sleep 却死活不醒
TinyGo 的 machine.Sleep() 不自动注册唤醒源，必须手动使能——比如用按钮唤醒，得提前配置引脚为外部中断：
立即学习“go语言免费学习笔记（深入）”；
- STM32 平台：调用
machine.GPIO{Pin: machine.PA0}.Configure(&machine.GPIOConfig{Mode: machine.GPIO_INPUT_PULLUP})，再调machine.SetExtIntCallback(machine.PA0, onWake) - ESP32：需用
machine.Pin.INTERRUPT_LOW或INTERRUPT_HIGH显式指定触发边沿，否则默认不响应 - 常见现象：
sendto: no route to host是网络层错误，和睡眠唤醒无关；真正唤醒失败多因：RTC 未校准（导致定时唤醒漂移）、外部中断未清除标志位（唤醒一次后锁死）、或引脚被误配为模拟输入（失去数字中断能力）
WOL 唤醒不是“低功耗设备自身唤醒”，而是远程叫醒另一台机器
有人混淆概念：用 Go 发 Magic Packet 是让别人（比如一台关机的 PC）从 WOL 状态醒来，不是让本机变低功耗——这属于网络管理范畴，和 MCU 睡眠无关：
- 发包必须用 root 权限（Linux）或管理员权限（Windows），否则
operation not permitted - MAC 地址解析别用
strings.Replace粗暴删分隔符，应统一转小写后用net.ParseMAC；错误示例："00:11:22:33:44:55"和"00-11-22-33-44-55"都合法，但"00:11:22:33:44:5G"会静默失败 - 目标机器 BIOS 必须开启
Wake on LAN，且网卡在 S5 状态仍有 +5VSB 供电——很多 USB-C 供电主板不支持，必须插交流电
边缘 Agent 动态功耗调度：怎么避免“睡了又马上醒”
真实设备上最耗电的不是睡觉，而是频繁进出睡眠——每次唤醒都要重配时钟、初始化外设、重建网络连接。关键在节奏设计：
- 用负载预测代替固定间隔：比如温湿度变化率 machine.DEEPSLEEP 定时唤醒
- 通信合并：攒够 3 条传感器数据再发一次 MQTT，比每条都发节省 70% 射频开启时间
- 错误模式：
for { read(); upload(); time.Sleep(1 * time.Second) }—— 这根本没进硬件睡眠，只是协程停顿；正确写法是machine.Sleep(machine.DEEPSLEEP)后靠 RTC 中断跳回循环起点
最容易被忽略的一点：唤醒后的第一件事不是干活，而是检查上次任务是否真的完成——比如上传失败就该重试，而不是直接清空缓冲区再睡，否则数据就丢了。
