WebSocket是独立于HTTP的全双工通信协议，基于TCP长连接，通过HTTP升级握手后切换为二进制帧通信；fetch和XMLHttpRequest无法替代，因其本质是请求-响应模型，不支持持久化双向通信。
WebSocket 不是 HTTP 的升级版，也不是“带状态的 AJAX”；它是一套独立的全双工通信协议，底层基于 TCP，浏览器和服务器一旦建立连接，就保持长链接，双方可以随时互发消息。
WebSocket 连接为什么不能用 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）。
立即学习“Java免费学习笔记（深入）”；
实操建议：
思乐微信商城微分销系统是以.net+access/mssql进行开发的微信分销系统。基于微信朋友圈的传播，是打造以分销商为中心的全新微信分销体验。让粉丝实时有效的获取朋友圈流量并快速分享购买分佣。因为是基于微信，所以要在微信上体验才更好。关注我们的微信核心功能：1、自动提示用户关注微信，解决一般程序无关注微信公众号的过程2、只要通过链接进一次，不过好久注册，什么方面注册，只要是用微信注册的，都会算
- 连接前先检查浏览器支持：
if ('WebSocket' in window) - URL 中不能带查询参数以外的路径段（如
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 WebSocket - 首次重试延时 1s，之后每次翻倍（1s → 2s → 4s），上限建议 30s
- 超过 5 次失败后暂停自动重连，提示用户手动刷新
- 监听
visibilitychange事件：页面隐藏时暂停重连，显示时再检查连接状态
真正难的不是写几行 new WebSocket，而是处理好断网、重连、消息堆积、重复投递、心跳保活这些边界——它们不会出现在“Hello World”例子里，但线上系统天天撞上。
