断网补传后，几小时前的温度突然堆在当前时间，趋势图就失去了真实过程。
本文使用MQTT 3.1.1、Node-RED 0.19 与虚构设备消息。从能通信走向稳定运行，需要对离线、重复、乱序和恢复建立明确语义。本文使用演示身份和事件，不连接真实控制负载，也没有声称取得未经记录的现场效果。
1. 从现象推到机制
设备采样时间表示物理观察时刻，服务接收时间表示进入系统时刻，两者差值还受时钟偏差影响。设备无可靠时钟时可以保留单调序号和网关接收时间，并明确时间质量，不编造精确日期。
图中的四个节点分别表示物理采样、设备缓存、服务接收、趋势告警。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用合成缓存样本模拟延迟上报，趋势按已确认采样时间绘制，告警判断同时检查新鲜度。乱序和重复要按样本身份处理。
1
2
{"sample_id":"boot7-42","sampled_at":"2019-01-01T00:00:00Z",
"received_at":"2019-01-01T00:05:00Z","time_quality":"synced"}
保留设备、网关和服务端各自时间与状态，按固定故障顺序复现。每次恢复后检查数据归属和未完成工作，不只观察连接图标重新变绿。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 历史数据集中补传 | 不应伪装成当前实时采样 |
| 设备时钟明显回退 | 需要标记时间质量问题 |
| 同一样本重复到达 | 趋势中不应重复计数 |
对照 1：历史数据集中补传
不应伪装成当前实时采样。观察时记录原始采样与接收时刻。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：设备时钟明显回退
需要标记时间质量问题。观察时记录序号顺序与时间差异。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：同一样本重复到达
趋势中不应重复计数。观察时记录稳定样本身份。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
时钟同步也有误差，不能凭时间戳精确比较毫秒级先后。跨设备关联需明确允许窗口和不确定范围。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“同一样本重复到达”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
