WebSocket是浏览器与服务端建立持久双向通道的协议，其“实时性”取决于服务端逻辑、网络稳定性、错误恢复及消息序号处理；需用wss://URL创建实例，校验readyState后再send，手动实现带退避的重连，并在onmessage中安全解析JSON。
WebSocket 不是“实现”实时通信的方案，而是浏览器与服务端之间建立持久双向通道的协议；用 JavaScript 调用 WebSocket 构造函数就能发起连接，但能否真正“实时”取决于服务端逻辑、网络稳定性、错误恢复策略和消息序列处理是否到位。
如何用 WebSocket 构造函数建立连接
直接 new 一个实例是最简起点，但必须传入有效的 ws/wss URL，且不能跨域（除非服务端明确允许）：
const ws = new WebSocket('wss://api.example.com/realtime');常见错误现象：Failed to construct 'WebSocket': The URL 'http://...' is invalid —— 注意必须是 ws:// 或 wss://，不能写 http://；net::ERR_CONNECTION_REFUSED 表明后端没监听或地址不对；403 Forbidden 多因服务端校验 Origin 或 token 失败。
- 连接成功后触发
onopen回调，此时才能调用send() - 连接失败或关闭时，
onerror和onclose都可能触发，不要只监听其中一个 - 若需传递鉴权信息，建议通过 URL query 参数（如
wss://...?token=abc123），而非 header（浏览器不支持自定义握手头）
send() 发送数据前必须检查 readyState
很多人在页面加载完立刻调用 send()，却忽略连接尚未建立完成，导致静默失败。正确做法是只在 ws.readyState === WebSocket.OPEN 时发送：
立即学习“Java免费学习笔记（深入）”；
if (ws.readyState === WebSocket.OPEN) {
ws.send(JSON.stringify({ type: 'ping', data: Date.now() }));
} else if (ws.readyState === WebSocket.CONNECTING) {
// 可选择缓存消息，或等 onopen 后重发
}-
readyState有四个值：CONNECTING(0)、OPEN(1)、CLOSING(2)、CLOSED(3) - 不要依赖
setTimeout等待固定毫秒数来判断连接就绪——网络延迟不可控 - 二进制数据可直接传
ArrayBuffer或Blob，但 JSON 字符串仍需手动JSON.stringify()
如何避免 onmessage 收到乱序或粘包数据
WebSocket 协议本身不保证应用层消息边界，浏览器会把多个 send() 合并为一个帧，或把大消息拆成多个帧；但 onmessage 每次触发都对应一个完整帧（文本或二进制），所以“粘包”问题在浏览器端几乎不存在 —— 真正的风险来自服务端未按帧发送，或前端未正确解析多层嵌套结构。
- 服务端若用 Node.js 的
ws库，确保每次socket.send()发送的是独立 JSON 字符串，而非流式拼接 - 前端收到字符串后，应包裹
try/catch做JSON.parse()，防止某条异常消息阻塞后续处理 - 若需严格顺序（如聊天消息 ID 递增），应在消息体中携带序号，并在前端做去重和排序缓冲，不能依赖接收顺序
为什么 onclose 触发后无法自动重连
WebSocket 连接断开后不会自动重试，必须手动实现重连逻辑。简单轮询重连容易引发雪崩，合理做法是带退避策略：
let reconnectTimeout = 1000;
function connect() {
ws = new WebSocket(url);
ws.onclose = () => {
setTimeout(() => {
connect();
reconnectTimeout = Math.min(reconnectTimeout * 2, 30000);
}, reconnectTimeout);
};
}- 服务端主动关闭时会传
event.code和event.reason，比如1001（going away）、4000+（自定义业务码），可用于区分是否需要重连 - 频繁
onerror+onclose循环可能是服务端证书过期（wss）、反向代理超时（如 Nginx 默认 60s 关闭空闲连接）、或客户端休眠唤醒后 socket 状态未同步 - 移动端切后台再切回时，部分浏览器会冻结 WebSocket，需监听
visibilitychange并手动重建连接
真正难的不是打开连接，而是让连接在弱网、切后台、服务重启、DNS 变更等场景下持续可用；多数线上问题出在重连时机判断、消息确认机制缺失、以及对 readyState 的误用上。
