能耗监测系统最怕的不是断网，而是断网期间的数据永远消失。楼宇项目里，弱电井断电检修、运营商链路抖动、汇聚交换机重启都是家常便饭，一次几小时的断网，如果设备端没有缓存与续传机制，平台侧就是一段刺眼的空白——后面的能耗分析、报警追溯、双控核算全都会被这段空白卡住。断网续传听起来只是“先把数据存下来，网络恢复后再补传”，但真正落到工程上，缓存存多久、断点记在哪里、重复数据怎么去重、缓存满了怎么办，每一个细节没做好都会丢数。本文梳理断网续传机制的完整设计要点，附现场验证方法。

断网为什么会丢数据：链路各层的缓存真相

先把丢数的原因看清楚。一条典型的监测链路是：传感器采集 → 控制器或网关汇聚 → 平台接收入库。断网发生在最后一跳时，前面的环节大多还在正常运转：传感器照采，控制器照存。问题在于各层的缓存能力差异巨大。传感器本体的存储往往只够几十条缓存或根本没有；控制器和边缘数据管理器才有像样的本地存储，能撑几小时到几天的数据量。如果采集端没有任何本地缓存，断网的每一分钟都是永久的数据空洞。设计的第一原则很朴素：数据在哪里产生，缓存就应该在哪里起步，越靠近数据源，丢数风险越小。

续传设计的五个工程细节

一是本地缓存的容量与时长估算。先算清楚最坏情况：站点最长可能断网多久（楼宇项目建议按七十二小时设计），断网期间的数据量有多大（测点数乘以采集周期乘以单条数据长度），再反推需要的存储容量，并预留一倍冗余。闪存写入有寿命，高频采集的场景要注意写入放大问题，可采用先内存缓冲、达到一定条数再批量落盘的方式降低擦写次数。

二是序列号与时间戳双保险。每条数据在产生时就打上单调递增的序列号和采集时刻的本地时间戳，补传时按序列号排序上报。只依赖时间戳有两个坑：多通道设备各通道时钟可能有毫秒级偏差，平台侧按时间戳归并容易错序；设备重启后时钟未同步就补传，时间戳整体漂移。序列号解决顺序问题，时间戳解决语义问题，两个都要。设备时钟靠 NTP 校时，断网期间时钟走偏的误差要在恢复后做平台侧修正。

三是去重与补拉机制。续传最常见的数据质量问题是重复：网络恢复后设备把缓存全量重发，而平台在断网边缘已经收到一部分，同一测点同一时刻出现两条记录。去重规则应在平台侧实现，以测点加采集时间（允许一个采集周期的容差）为键判重。另一个方向是补拉：平台发现某站点数据断流后，在链路恢复时主动向设备查询断网期间的缓存区间，把缺口拉齐——这对平台上层应用更友好，因为补拉由平台发起，入库时序可控。工程上建议设备主动续传与平台主动补拉两者都实现，互为兜底。

四是缓存满溢的降级策略。断网超过设计时长时缓存必然写满，此时必须有明确的降级规则而不是静默丢弃。常见做法是“保留最新、压缩最旧”：最旧的数据按小时聚合降精度保留，最新数据保持原始精度，并在恢复上报时打上降精度标记，让平台侧知道这段数据的时间颗粒度变粗了。绝对要避免的是无声覆盖——数据悄悄没了，平台日志里却一切正常，等到月底核算才发现对不上账。

五是恢复后的上报节奏控制。几百个站点同时恢复联网，若各自全速补传，瞬时流量会把刚恢复的链路再次冲垮。续传协议要带节流：按批次错峰上报、单站点限速、平台侧按站点队列调度。对能耗类非实时数据，补传的优先级天然低于实时数据，恢复后应先保障实时链路，再慢慢补历史。

断网续传设计要点速查

现场验证方法

断网续传不能只看说明书，要在现场做破坏性验证。四个必做实验：拔网线测试，在采集高峰期直接拔掉上行网线，保持规定时长后恢复，核对平台侧数据完整性；重启测试，在断网状态下重启边缘设备，确认断点信息在重启后依然保留、补传不重复不遗漏；满溢测试，缩短缓存容量配置模拟写满，验证降级策略按设计生效；并发恢复测试，多站点同时恢复，观察平台入库时序和链路负载。四个实验都过了，续传机制才算真正可用。

断网续传是能耗监测系统数据完整性的最后一道防线。选设备时就要把续传能力作为硬指标：边缘数据管理器的本地缓存容量、网关的断网缓存策略、控制器的暂存能力，都要写进招标技术条款，而不是等丢数了再补救。

延伸阅读：ECG100边缘数据管理器在楼宇能耗监测中的本地缓存与断点续传配置；能耗网关断网期间的边缘缓存策略与恢复补传实测；ECC200网络控制器数据采集层的断网暂存与序列号管理；ZYH-ZHQ以太网转换器在监测链路有线备份中的应用；传感器固件OTA升级：批量运维最佳实践。