WebSocket是独立于HTTP的全双工通信协议,基于TCP长连接,通过HTTP升级握手后切换为二进制帧通信;fetch和XMLHttpRequest无法替代,因其本质是请求-响应模型,不支持持久化双向通信。
WebSocket 不是 HTTP 的升级版,也不是“带状态的 AJAX”;它是一套独立的全双工通信协议,底层基于 TCP,浏览器和服务器一旦建立连接,就保持长链接,双方可以随时互发消息。
fetch 或 XMLHttpRequest 替代HTTP 协议本身是请求-响应模型:客户端发一次请求,服务端回一次响应,连接随即关闭。即使使用 fetch 配合轮询(polling)或长轮询(long polling),本质仍是反复建连、断连,有延迟、有开销、无法真正“实时”。而 WebSocket 在握手阶段复用 HTTP(发送 Upgrade: websocket 请求),一旦成功,协议就切换为二进制帧通信,不再受限于 HTTP 的 request/response 生命周期。
常见错误现象:
fetch('/ws') 试图“打开 WebSocket”,结果返回 405 或 400 —— 因为 fetch 根本不支持 WebSocket 握手setInterval 里每秒 fetch('/api/updates'),后端压力大、前端卡顿、消息延迟固定在 1s 以上WebSocket 构造函数建立连接浏览器原生支持 WebSocket,无需额外库。关键点在于 URL 必须以 ws://(开发)或 wss://(生产)开头,且服务端必须运行 WebSocket 服务(如 Node.js 的 ws 库、Python 的 websockets)。
实操建议:
if ('WebSocket' in window)
ws://localhost:3000/chat 可以,但 ws://localhost:3000/chat/ 某些服务端会拒绝)onerror 和 onclose,需主动监听readyState 的情况下直接调用 send(),否则报错 InvalidStateError
const socket = new WebSocket('wss://echo.websocket.org');
socket.onopen = () => {
console.log('已连接');
socket.send('hello server');
};
socket.onmessage = (event) => {
console.log('收到:', event.data);
};
socket.onerror = (error) => {
console.error('连接出错:', error);
};
socket.onclose = () => {
console.log('连接已关闭');
};
send
() 能传什么类型?为什么有时发不出去WebSocket.send() 只接受 string、ArrayBuffer、Blob 或 TypedArray。传 Object 或 number 会静默失败(不报错但服务端收不到),因为 JS 会尝试调用 .toString(),结果可能是 [object Object] 或数字字符串,而非预期 JSON。
常见错误场景:
socket.send({ id: 1, msg: 'hi' }) → 实际发送的是 [object Object]
socket.send(JSON.stringify(data)) 是正确做法,但记得服务端也要做 JSON.parse()
Uint8Array 或 ArrayBuffer,不要转成 base64 字符串再 send,徒增体积和编码开销onclose
onclose 只告诉你断了,但不区分是网络闪断、服务重启还是用户切后台。单纯在里面立刻 new WebSocket(...) 容易触发雪崩重连(尤其在弱网下)。更稳妥的做法是加退避策略 + 状态锁。
实操要点:
isConnecting 防止并发多次 new WebSocketvisibilitychange 事件:页面隐藏时暂停重连,显示时再检查连接状态真正难的不是写几行 new WebSocket,而是处理好断网、重连、消息堆积、重复投递、心跳保活这些边界——它们不会出现在“Hello World”例子里,但线上系统天天撞上。