javascript如何使用WebSocket_如何实现实时通信【教程】_网络技术

WebSocket连接失败主因是服务端未启动、协议不匹配或浏览器拦截；需核对ws/wss协议、检查Network中101状态码、确保后端正确响应升级请求，并避免file://协议下使用。

WebSocket 连接失败的常见原因和检查点

直接 new WebSocket() 报错或连接立刻关闭，大概率不是代码写错了，而是服务端没起来、URL 协议不匹配，或者浏览器被拦截。先确认 ws:// 或 wss:// 和后端实际暴露的协议一致；本地开发时如果后端用 http://localhost:3000，前端却连 ws://127.0.0.1:8080，跨域+协议+端口全错，必然失败。

检查浏览器控制台 Network 标签页里 WebSocket 请求的状态码：101 Switching Protocols 才算成功握手，否则看 Response Headers 有没有 Sec-WebSocket-Accept
确保后端已正确响应 WebSocket 升级请求（比如 Node.js 的 ws 库需显式 server.handle Upgrade()）
Chrome 浏览器在非 http:// 或 https:// 页面（如 file://）下会静默拒绝 ws:// 连接，必须走本地服务器

onmessage 回调里如何安全解析 JSON 数据

WebSocket.onmessage 接收到的 event.data 是 string 或 Blob，不是自动 JSON 解析后的对象。直接 JSON.parse(event.data) 可能抛错，尤其当服务端发来非 JSON 字符串（比如心跳 ping/pong、二进制帧、调试日志）时。

始终用 try...catch 包裹 JSON.parse()，避免整个回调崩溃
提前判断 typeof event.data === 'string'，跳过 Blob 或 ArrayBuffer 类型（除非你明确要处理二进制）
服务端最好统一加个 type 字段，比如 { "type": "message", "payload": {...} }，前端按 type 分发逻辑，而不是硬解析所有 data

如何避免重复连接和自动重连失控

页面刷新、网络抖动、服务端重启都会导致连接断开。但 onclose 里直接 new WebSocket() 会引发无限重连风暴，尤其配合未加延迟的递归调用。

用布尔标志位（如 let isConnecting = false）防止 onclose 多次触发新建实例
重连前加指数退避：第一次等 1s，第二次 2s，第三次 4s……上限建议 30s，避免压垮服务端
限制最大重连次数（比如 5 次），之后应提示用户“连接异常”，并提供手动重试按钮（reconnectBtn.addEventListener('click', initWS)）
在 onopen 中清除之前的重连定时器，避免旧定时器在新连接建立后仍执行

发送消息前必须检查 readyState

WebSocket.readyState 不是永远等于 WebSocket.OPEN。页面刚加载时是 0（CONNECTING），断连瞬间变成 0 或 3（CLOSED），此时调用 send() 会直接报错 InvalidStateError，且不会进入 onerror。

每次 send() 前必须判断：if (ws.readyState === WebSocket.OPEN) { ws.send(...) }
如果处于 CONNECTING（0）状态，可把消息暂存到队列（pendingMessages.push(msg)），并在 onopen 中批量发送
不要依赖 onerror 捕获 send 失败——它只对底层传输错误有效，readyState 不对时根本不会触发

WebSocket 的核心复杂点不在 API 本身，而在于状态管理：连接中、重连中、已关闭、正在发送……这些状态之间切换频繁，稍不留神就会出现“明明连上了却收不到消息”或“疯狂创建新连接却不销毁旧实例”。真实项目里，建议封装一个带状态机的 WebSocketClient 类，而不是裸用原生 API。

# javascript # java # js # 前端 # node.js # json # node # 浏览器 # 端口 # websocket # 后端

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】