WebSocket是JavaScript实时通信唯一标准方案；连接失败主因是环境或服务端配置，如协议不匹配（wss需HTTPS）、端口错误、Origin校验缺失、代理未透传Upgrade头；onmessage需先判data类型再JSON解析；close事件中reason/code仅服务端主动关闭时可靠，异常断连恒为1006；核心难点在重连、消息队列、心跳等自实现逻辑。
WebSocket 是 JavaScript 实现实时通信的唯一标准方案，其他如轮询、SSE 都是妥协或补充手段。
WebSocket 连接失败的常见原因和检查点
连接不上不是代码写错了，大概率是环境或服务端配置问题：
-
ws://协议不能在https://页面中使用，必须用wss://（否则浏览器直接拒绝） - 服务端没启动或监听地址不对，比如前端连
ws://localhost:8080，但后端实际跑在3000端口 -
跨域不是 WebSocket 的问题——它本身不受同源策略限制，但服务端必须明确允许该 Origin（比如 Express + ws 库需手动校验
req.headers.origin） - 代理或 Nginx 没开启 WebSocket 支持：
Upgrade和Connection头被过滤会导致握手 400
如何正确处理 onmessage 中的 JSON 数据
服务端发来的消息不一定是字符串，也可能是 ArrayBuffer（尤其传输二进制时），直接 JSON.parse() 会报错：
- 先判断
event.data类型：typeof event.data === 'string'再解析 - 如果服务端明确约定只发 JSON 字符串，可在连接建立后加一层封装：
socket.onmessage = (e) => {
if (typeof e.data === 'string') {
try {
const msg = JSON.parse(e.data);
// 处理业务逻辑
} catch (err) {
console.warn('Invalid JSON:', e.data);
}
}
}; - 避免在
onmessage里做重解析或深层嵌套转换，容易阻塞主线程；复杂结构建议用ArrayBuffer+TextDecoder或JSON.parse后立刻交由Web Worker
为什么 close 事件里拿不到服务端传来的 reason 和 code
close 事件的 event.code 和 event.reason 只有服务端主动调用 close(code, reason) 并且 code 在 3000–4999 范围内时才可靠传递。浏览器发起的断连（如网络中断、页面关闭）只会返回默认 code=1006，reason 为空字符串。
立即学习“Java免费学习笔记（深入）”；
- 不要依赖
event.reason做错误分类，应结合event.code和连接状态（如socket.readyState !== WebSocket.OPEN）做降级处理 - 需要传递上下文信息，应在断开前主动发一条
type: "disconnect"的控制消息，而不是等 close 事件 -
1000表示正常关闭，1001是服务端/客户端主动离开（如页面卸载），1006是异常关闭（无法恢复），这些 code 是标准化的，可查 IANA 注册表
真正难的不是建立连接，而是断线重连策略、消息队列暂存、重复投递识别、心跳保活节奏——这些不在 WebSocket API 里，得自己补全。
