WebSocket与HTTP是分工关系：HTTP负责拉取/提交，WebSocket负责实时双向通信；握手用HTTP，之后脱离HTTP独立传输；需Nginx等中间件支持升级配置，且必须实现心跳、重连与状态管理。
WebSocket 和 HTTP 不是“替代关系”，而是“分工关系”：HTTP 负责拉取、加载、提交，WebSocket 负责保持连接、实时互推。选错协议会导致轮询压垮后端、消息延迟卡顿、连接频繁断开等实际问题。
WebSocket 握手阶段用的是 HTTP，之后就彻底脱离 HTTP
客户端发起 ws:// 或 wss:// 连接时，底层发送的是一个带 Upgrade: websocket 和 Connection: Upgrade 头的 HTTP 请求；服务器返回 101 Switching Protocols 后，TCP 连接不再解析 HTTP 报文，后续所有数据都按 WebSocket 帧格式传输。
- 这意味着：Nginx / CDN / 防火墙必须明确支持 WebSocket 升级，否则会在握手阶段直接拒绝或超时
- 常见错误现象：
ERR_CONNECTION_REFUSED、net::ERR_INCOMPLETE_CHUNKED_ENCODING、浏览器控制台显示Failed to complete handshake - 关键配置项：Nginx 中需设置
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"
HTTP 是单向请求-响应，WebSocket 是双向自由通信
HTTP 下，服务器永远不能“主动”发数据给客户端——哪怕只是通知“有新消息了”，也得靠客户端定时问（轮询）或长连接挂起（long polling）。而 WebSocket 连接建立后，服务端可随时调用 ws.send() 推送，客户端也无需等待就能收。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 典型场景对比：
GET /api/messages?since=123（HTTP 拉取） vsws.send({type: 'new_message', data: ...})（WebSocket 主动推） - 性能影响：1000 个在线用户，每秒轮询一次 HTTP，会产生 1000 QPS；用 WebSocket 则只有 1000 个长连接 + 零请求开销
- 容易踩的坑：误把 WebSocket 当成“更快的 HTTP”，在服务端仍用同步阻塞逻辑处理消息，导致推送延迟或连接假死
WebSocket 适合这些真实场景，不是所有“实时”都需要它
是否上 WebSocket，取决于“谁需要主动推”和“延迟容忍度”。不是所有标着“实时”的功能都值得引入长连接。
- 真正适合：
在线聊天（双方随时打字）、协作文档光标同步（毫秒级位置更新）、交易行情推送（价格变动需亚秒送达）、扫码登录状态轮询替代（避免每 2s 发一次GET /auth/status） - 明显不适合：
用户头像上传（仍是请求-响应）、分页列表加载（拉取一次即可）、埋点上报（用sendBeacon或批量 HTTP 更稳） - 灰色地带：
通知中心红点——若只关心“有无新通知”，用 Server-Sent Events（SSE）更轻量；若还需同步未读数、分类折叠状态，则 WebSocket 更可控
真正容易被忽略的点：WebSocket 连接不是“建好就一劳永逸”。网络抖动、NAT 超时、代理中断都会静默断连，客户端必须实现重连逻辑（带退避策略），服务端要能识别重复连接并踢旧保新。没有心跳保活、没有连接状态管理、没有错误降级方案的 WebSocket，上线后比轮询还难排查问题。
