WebSocket实时传感器数据处理需确保数据可用性：强制type字段区分消息类型，设备端和服务端两级数值校验，设备生成时间戳并校验窗口，断网时本地缓存并序列化重传。
WebSocket 处理实时传感器数据流，关键不在“连得上”，而在“数据能用”——即收到的数据要能被准确识别、安全落库、稳定渲染，不因跳变、乱序、丢包或时间错位导致前端图表失真、告警误判或分析失效。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
消息必须带 type 字段，且服务端与前端统一按 type 分发处理
裸 JSON 如 {"temp":25.1,"hum":60} 看似简洁，实则危险。它无法区分是设备状态上报、控制指令反馈，还是心跳保活。一旦温湿度、电量、信号强度混报，字段易覆盖或类型错配（比如把字符串当数字解析）。
- 所有上报消息顶层强制加
"type": "status"（或"control_ack"、"heartbeat"） - 服务端收到后先校验
type是否合法，再匹配对应 schema 解析，避免直接取data.temp导致undefined - 前端也按
type路由：if (msg.type === 'status') updateDashboard(msg); else if (msg.type === 'heartbeat') keepAlive();
传感器数值需在设备端和服务端两级校验
DHT22 温度突跳到 120℃、光敏电阻输出负值、电池电压读成 0.1V——这类异常在真实环境中极常见。靠前端 JS 修复不可靠（JS 可能被禁用，数据已入库）。
- 设备端固件做第一道过滤：ESPHome 中用 lambda 判断
if (x < -40 || x > 85) return NAN; - 服务端接收到 WebSocket 消息后立即归一化：
humidity = Math.min(Math.max(data.humidity, 0), 100) - 对时间敏感字段（如
battery_voltage），建议同时校验变化率（如单次跃变超过 0.5V 触发标记，供后续人工复核）
时间戳必须由设备生成并传入，禁止服务端补填
服务端用 Date.now() 打时间戳，会导致采样时刻丢失。空调启动瞬间的温升曲线若用接收时间对齐，因果关系就错了；多设备协同分析时，时序完全错乱。
- 设备端每次上报携带
ts字段（毫秒级整数）或timestamp（ISO 8601 字符串） - ESP32 推荐用 SNTP 同步后调用
gettimeofday()；ESPHome 可直接用now().timestamp() - 服务端不做时间覆盖，仅校验
ts是否在合理窗口内（如距当前时间 ±5 秒），超窗则打标为“时钟未同步”，不参与聚合计算
断网期间数据需本地缓存，恢复后批量重传
WiFi 临时中断、基站切换、电源波动都会导致连接闪断。若设备不缓存，这段数据就永久丢失。
- 设备端启用环形缓冲区（如 1KB Flash 存储最近 30 条完整 status 消息）
- 连接重建后，先发
{"type":"replay_start","seq":123}，再逐条重传，服务端按seq去重合并 - 重传完成发送
{"type":"replay_end","seq":152}，服务端据此判断是否补齐
不复杂但容易忽略。
