WebSocket消息无响应的90%原因并非连接失败，而是消息在发送路径中某环节丢失：握手未成功、帧类型不匹配、二进制处理缺失、中间件超时断连、JSON嵌套解析错误等，需逐段用WS Frames面板和服务端日志验证。
WebSocket发送消息没反应，90%不是连不上，而是消息根本没进服务端逻辑、或服务端发出去但前端没收到——得按“发送路径”一节节卡点验证。
WebSocket.send()调用后服务端完全没日志？先看握手是否真成功
浏览器 Network → WS 标签页里看不到连接条目，说明压根没发出 Upgrade 请求。常见原因：
-
ws://地址写成http://或漏了端口（比如后端监听8080，前端却连ws://localhost/ws） - URL 中带
token参数但未 encode，如token=abc+def里的+被当空格解析，导致后端鉴权失败静默拒绝 - 反向代理（Nginx / Spring Cloud Gateway）没透传
Upgrade和Connection: upgrade头，返回 400 或 426 错误 - 后端 WebSocket 端点路径和前端请求路径不一致，比如后端注册的是
/ws/{userId}，前端却连/ws（Spring Boot 默认不匹配）
验证方式：用 curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" ws://localhost:8080/ws?token=xxx，看到 101 Switching Protocols 才算握手成功。
服务端有日志但 onmessage 不触发？检查帧类型与二进制处理
前端 socket.send() 发的是 ArrayBuffer 或 Blob，而 Java 后端 @OnMessage 方法只标注了 String 参数，就会直接丢弃——不报错、不进方法、日志全无。
- 在 Chrome DevTools 的 WS → Frames 标签页里，确认发送帧的 Type 是
Text还是Binary - Java 后端必须配两个
@OnMessage方法：@OnMessage public void onText(String msg)+@OnMessage public void onBinary(byte[] data) - Node.js 的
ws库不能直接send({type:'msg'})，必须send(JSON.stringify({...}))，否则静默失败 - PHP/Go 原生 socket 若未实现 WebSocket 帧解码，
socket_read()拿到的是带掩码的原始帧，直接json_decode()必然失败
消息发到服务端也响应了，但前端 onmessage 仍不执行？盯紧 readyState 和关闭时机
连接看似 OPEN，但可能刚发完消息就进入 CLOSING，导致响应被丢弃。典型诱因：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 中间件（Nginx 默认 60s、某些云 WAF 30s）空闲超时主动断连，前端
socket.readyState还是1，但后续 send/receive 实际失效 - Java 后端用
AsyncRemote.sendBinary()未等异步完成就 return，或没调flush()，消息滞留在缓冲区 - 前端在
onclose里没重置监听器，重连后新 socket 的onmessage没绑定，旧句柄已销毁 - VueUse 的
useWebSocket默认启用自动重连，但若onError里没event.preventDefault()，可能触发多次并发连接，状态混乱
建议在 onopen 后立即启动 setInterval(() => socket.send('ping'), 30000)，并确保服务端对 ping 有响应或至少不关连。
前后端结构嵌套两层 JSON，最容易漏掉一层 JSON.parse()
像这种发送格式：{"type":"demo-message-send","content":"{\"text\":\"hi\",\"toUserId\":\"123\"}"}，前端接收后必须分两步解析：
- 第一层：
const msg = JSON.parse(event.data) - 第二层：
const content = JSON.parse(msg.content)（注意：如果content是字符串才需要这步）
如果后端返回的 content 字段本身就是对象（非字符串），前端还多 parse 一次，就会报 Unexpected token o in JSON at position 1；反之如果后端返回字符串但前端少 parse 一次，content.text 就是 undefined。最稳妥的方式是在 WS → Frames 里直接看原始 payload 内容，确认结构再写解析逻辑。
真正难排查的永远不是“连不上”，而是“看起来连着，但消息像掉进黑洞”。每一步都得用 Frames 面板或服务端日志实锤，别信 readyState，也别猜 send() 返回值——它只表示放进队列，不代表送达。
