设备端不支持websocket协议栈是指令下发失败主因，需通过websockify等方案做websocket↔tcp协议转换，并在前后端手动实现ack机制与二进制帧处理。
直接用 WebSocket 向 IoT 设备下发指令，90% 的失败不是因为前端写错了 send()，而是设备端根本没接入 WebSocket 协议栈——它只认 TCP 或 MQTT。真正的指令下发链路，往往需要在服务端做协议转换。
设备不支持 WebSocket？先确认通信协议栈能力
绝大多数嵌入式 IoT 设备（如 ESP32、STM32+AT 模组、旧款 PLC）出厂固件仅实现 TCP/UDP 或 MQTT 客户端，不具备 WebSocket 解析能力。强行让设备直连 wss:// 会直接触发连接拒绝或握手失败（错误信息：HTTP 400 Bad Request 或静默断连）。
- 查设备手册关键词：“WebSocket client support”、“RFC 6455 compliant”——没提就是不支持
- 用
tcpdump或 Wireshark 抓包，看设备建连时是否发送Upgrade: websocket头——没有就说明它只走纯 TCP - ESP32 若用 Arduino Core，需确认是否启用了
WiFiClientSecure+WebSocketsClient库；裸机 SDK 更大概率只提供esp_tcpip_adapter
Websockify 是最轻量的 WebSocket ↔ TCP 转换方案
不需要改设备固件、不引入新服务框架，websockify 可以把任意 TCP 服务“伪装”成 WebSocket 服务端，前端发 ws:// 指令，它自动转成原始 TCP 字节流推给设备。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 启动命令示例：
websockify 8081 192.168.1.100:6000 --verbose，表示将ws://your-domain.com:8081的所有消息，原样转发到设备 IP 的6000端口 - 必须加
--verbose开关：它能打印每帧收发的十六进制数据，帮你确认指令是否被截断或乱序 - 设备端若要求粘包处理（如 Modbus TCP），需在
websockify后接一层代理（如 Node.js 的net.Socket）做缓冲解析——websockify本身不拆包
Spring Boot 后端做协议桥接时，别忽略二进制指令边界
很多控制指令（如固件升级包、图像帧、PWM 参数）是二进制的，但 Spring WebSocket 默认只处理文本帧。若前端用 ws.send(new Uint8Array([0x01, 0x02])) 发送，后端 TextMessage 会抛 IllegalArgumentException。
- 在
WebSocketHandler中重写handleBinaryMessage()，而不是只写handleTextMessage() - 配置里必须设
setMaxBinaryMessageBufferSize(1024 * 1024)（默认仅 64KB），否则大指令直接被容器丢弃 - 转发给设备前，建议用
ByteBuffer.wrap(byte[])显式构造字节流——避免String.getBytes()引入 UTF-8 编码污染
指令幂等性与设备端响应回传必须手动设计
WebSocket 本身不保证消息送达，也不定义 ACK 机制。前端调用 ws.send() 成功，只代表数据进了浏览器发送队列，不代表设备已执行。
- 必须约定双向 JSON 协议结构，例如下发指令带
"msg_id": "cmd_20260522_001"，设备执行完返回{"ack": "cmd_20260522_001", "status": "success"} - 前端要维护未确认指令的 Map，超时（如 5s）未收到 ACK 就触发重发——不能依赖
onclose自动重连，重连后原指令已丢失 - 设备固件若无心跳保活，TCP 层可能因 NAT 超时静默断连；建议在
websockify后加keepalive参数（如--heartbeat=30）
真正卡住项目的，从来不是 WebSocket 连接代码，而是设备端对帧格式、超时、重试、ACK 的实际实现程度。协议转换只是通道，指令语义和状态同步得靠前后端共同约定，且必须在真实设备上逐字节验证。
