基于 ESP32 的边缘网关断网续传实战：本地缓存、MQTT 离线消息与云端对账

基于 ESP32 的边缘网关断网续传实战：本地缓存、MQTT 离线消息与云端对账

做工业现场的设备接入，最容易被低估的一定是"网络"这件事。车间 WiFi 有覆盖死角，4G 模块在雨季掉信号，光纤被施工挖断，这些是常态而不是意外。于是会出现这样的场景：上午十点网关重启一次，下午两点去查当天能耗曲线，中间三个小时的数据整整齐齐断掉了，而设备日志里干干净净，什么异常都没有。设备不知道自己丢了数据，云端也查不出中间缺了多少，这种"静默丢数"比设备直接停机更难查。

第二个问题更隐蔽。现场同事的常规做法是"断了就重连，重连后从头再发一遍"。这会带来两个新麻烦：重连瞬间几十条历史数据一起往 Broker 灌，容易把链路和数据库一起压垮；MQTT 的 QoS 1 只保证"至少送达一次"，重发必然产生重复，而多数入库脚本用的是普通 INSERT，重复记录会直接把报表算错。

第三个问题是数据一致性。云端通常只能看到"已经收到的数据"，看不到"本该收到却没到的数据"。没有对账机制的话，数据缺口要等到月底结算、等到客户拿着电费单来质疑时才浮出水面，那时已无补救余地。

真正能落地的方案是三件套：边缘侧先把数据缓存住，网关侧用带唯一标识的报文支持按序补传，云端侧用幂等入库加每日对账把缺口找出来并驱动重传。这三件事必须同时具备，缺一环都会留下可追溯的坑。本文用一块 ESP32-WROOM-32E、两台 Modbus 从站和一个自建 Ubuntu 云服务器把链路完整走通，代码可直接使用。

一、为什么"直接重连重发"不够

断网续传不是"多写一个重连逻辑"，它至少包含持久化、幂等和一致性校验三件事，常见的重连重发方案只做了第一件的半成品。