构建 IoT/物联网应用时：应对网络不可靠、功耗受限…

用 Rust 开发传感器、网关、MQTT 或边缘计算类物联网应用时，按网络、功耗、安全、升级四类约束落地的具体实现清单。

适用场景

解决思路

1. 网络可能随时失败时，采用离线优先（offline-first）：在设备本地做缓冲队列，并持久化到本地存储，等网络恢复再 flush 上报。
2. 为所有网络请求加重试逻辑，并使用指数退避（exponential backoff），避免数据丢失和惊群。
3. 为省电：设备在非工作期间进入睡眠模式，用定时器/唤醒事件（timer-based wake）驱动周期上报，而不是让无线电常开。
4. 只在发送数据的瞬间打开无线电，两次发送之间保持睡眠，避免“always-on radio”导致电池耗尽。
5. 在资源受限的 MCU 上优先使用 no_std，最小化内存分配（minimal alloc），选用高效算法。
6. 所有通信必须加密：MQTT 走 TLS，消息签名；避免明文 MQTT 带来的安全风险。
7. 固件 OTA 升级必须签名（signed firmware），并具备回滚能力，保证升级失败可恢复。
8. 加入看门狗（watchdog）与完善的错误处理，使设备具备自恢复（self-recovery）能力。
9. 按运行环境选技术栈：Linux 网关用 tokio + std（crate 如 rumqttc、reqwest）；MCU 设备用 embassy + no_std（embedded-hal）；混合场景拆分工作负载，两端各用各的栈。
10. 选型参考：MQTT(std) 用 rumqttc / paho-mqtt；嵌入式用 embedded-hal、embassy；异步(std) 用 tokio；异步(no_std) 用 embassy；日志(no_std) 用 defmt；日志(std) 用 tracing。
11. 设备通信采用 Pub/Sub 模式，用 MQTT topic 组织，例如 devices/<id>/commands 订阅命令、devices/<id>/telemetry 发布遥测。
12. 采用边缘计算模式：在设备/网关本地先过滤、处理后，只把有价值的数据上传，减少带宽与功耗。
13. 采用存储转发（store & forward）模式应对网络中断：本地排队，网络恢复后按序补发。
14. 实现电源管理模式：睡眠 + 唤醒事件配合，按业务需要平衡上报频率与电池寿命。
15. MQTT 客户端设置 keep_alive（如 30 秒），订阅命令主题时用 QoS::AtLeastOnce，发布遥测时也用 QoS::AtLeastOnce。
16. MQTT 事件循环中 poll 出错时记录错误并等待一段固定时间（如 5 秒）后继续重试，而不是直接崩溃退出。
17. 定期读取传感器数据并按固定间隔（如 60 秒）发布遥测；把发布循环放到独立 task 中与事件处理解耦。
18. 避免四个常见错误：无重试逻辑（改为指数退避）、无线电常开（改为发送间隙睡眠）、未加密 MQTT（改为 TLS）、无本地缓冲（改为本地持久化）。
19. 离线下沉到实现层时：离线优先 = 本地队列 + flush；省电 = 定时唤醒；网络可靠 = 重试 + backoff；安全 = rustls / native-tls。
20. 相关主题按需查阅：嵌入式模式见 domain-embedded，异步模式见 m07-concurrency，错误恢复见 m13-domain-error，性能见 m10-performance。

适用边界 · 注意事项

• 设备始终供电、网络稳定且带宽充足的纯云端服务，不必引入睡眠模式、本地持久化缓冲等复杂度。
• 不需要极端资源/功耗约束的普通后端服务，无需为了 IoT 而强制使用 no_std 或 embassy。
• 项目不使用 Rust 或不涉及设备侧通信协议（MQTT/嵌入式）时，本经验中的 crate 与代码模式不直接适用。