WebSocket 是全双工、长生命周期的 TCP 连接，握手复用 HTTP 但后续脱离其协议栈，以轻量帧通信；原生 JS 通过 WebSocket 构造函数创建，依赖 onopen 发送数据，不自动重连，需手动实现并注意代理、CDN、兼容性等部署限制。
WebSocket 不是 HTTP 的升级版，也不是轮询的替代包装，它是浏览器与服务器之间建立的**全双工、长生命周期 TCP 连接**——连接一旦建立，双方可随时主动收发数据，没有请求-响应约束。
WebSocket 与普通 HTTP 请求的根本区别
HTTP 是无状态、单向、短连接：客户端发请求，服务端回响应，连接立刻关闭。而 WebSocket 在握手阶段复用 HTTP（用 Upgrade: websocket 头），但之后完全脱离 HTTP 协议栈，进入二进制帧通信模式。
- 每次 HTTP 请求都带完整头信息（可能几百字节），WebSocket 帧头部最小仅 2 字节
- HTTP 轮询需反复建连、TLS 握手，WebSocket 复用一个连接，首屏后通信开销趋近于零
- 服务端无法主动推数据给 HTTP 客户端；WebSocket 下
server.send()可随时触发客户端onmessage
如何用原生 JavaScript 创建并使用 WebSocket
核心是 WebSocket 构造函数，它接受 URL（必须是 wss:// 或 ws://）并立即发起握手。连接状态和消息通过事件监听：
const ws = new WebSocket('wss://echo.websocket.events');
ws.onopen = () => {
console.log('已连接');
ws.send('hello'); // 连接就绪后才能 send
};
ws.onmessage = (event) => {
console.log('收到:', event.data); // event.data 总是字符串或 Blob
};
ws.onerror = (error) => {
console.error('连接异常', error);
};
ws.onclose = (event) => {
console.log('断开，代码:', event.code, '原因:', event.reason);
};
-
ws.readyState有四个值：0（CONNECTING）、1（OPEN）、2（CLOSING）、3（CLOSED），别在0时调send() -
event.data类型取决于服务端发送的内容：文本为string，二进制为Blob或ArrayBuffer，可用ws.binaryType = 'arraybuffer'统一处理 - 不要用
setTimeout轮询readyState，应严格依赖onopen回调
为什么 WebSocket 会“自动重连”不是默认行为
浏览器原生 WebSocket 对象**不提供自动重连**。断开后对象即失效，再次 new WebSocket() 才算新连接。常见错误是监听 onclose 后直接 ws = new WebSocket(...)，但旧 ws 引用未清理，导致内存泄漏和重复监听。
立即学习“Java免费学习笔记（深入）”；
- 重连需手动实现：记录重试次数、指数退避（如 1s → 2s → 4s）、最大尝试上限
- 避免在
onclose中立即重连，先清空定时器、取消未完成的send()、重置onmessage绑定 - 服务端若返回
event.code === 4000，通常表示业务层拒绝接入，不应盲目重连
实际部署中容易被忽略的三个硬性限制
开发时本地 ws://localhost:3000 很顺畅，上线后常卡在连接失败——问题往往不在代码逻辑，而在基础设施层面：
- 反向代理（如 Nginx）必须显式透传 WebSocket 头：
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade" - CDN 或 WAF 默认拦截非标准 HTTP 方法/头，
Upgrade请求会被 403 拦截，需在 CDN 控制台开启 WebSocket 支持 - 移动端某些 WebView（如早期 Android 4.x）不支持
WebSocket，降级方案不能只靠typeof WebSocket !== 'undefined'，要加try/catch new WebSocket()实测
真正难的不是写通第一行 ws.send()，而是让连接在弱网、代理、混合 CDN、老旧终端下稳定存活超过 30 分钟——这需要服务端心跳保活、客户端网络状态感知、以及对 close 事件中 code 和 reason 的精确分类处理。
