WebSocket与HTTP非替代关系，而是各适其用：HTTP适用于单次请求-响应场景，如登录、获取文章；WebSocket适用于持续双向低延迟通信，如协作文档、实时通知，其通过HTTP升级握手建立持久连接，但带来连接管理、可靠性及扩展性等工程复杂度。
WebSocket 和 HTTP 不是“谁替代谁”的关系，而是解决不同问题的工具。选错协议不会报错，但会带来隐性成本：比如用 HTTP 轮询做聊天功能，后端 QPS 翻 10 倍、前端电量掉得快、消息延迟忽高忽低；反过来，用 WebSocket 去加载一张 PNG 图片，反而多出握手开销和连接管理负担。
HTTP 是请求-响应模型，每次通信都重连
浏览器发一个 GET /api/user，服务器回一个 JSON，TCP 连接就关了。下一次请求（哪怕 100ms 后）必须重新三次握手、发完整 Header（含 Cookie、User-Agent、Accept 等），典型 Header 大小在 700–800 bytes。这意味着：
- 高频小数据交互（如每秒心跳、打字提示）时，Header 开销远超实际 payload
- 服务器无法主动通知客户端：“有新消息了”——只能等客户端再问一遍
- HTTP/2 虽支持多路复用，但仍是请求-响应语义，不改变“服务器不能先开口”这一根本限制
WebSocket 通过 HTTP 升级建立持久双工连接
它不是独立协议栈，而是借道 HTTP 完成初始握手：Upgrade: websocket + Connection: Upgrade。握手成功后，底层 TCP 连接被复用，后续收发数据帧头仅 2–14 bytes，且双方随时可发消息。关键点：
- 连接生命周期由应用控制，可维持数小时甚至数天（需配合心跳保活）
- 服务端能立刻推消息，比如订单状态变更、协作光标移动、股价跳动
- 不兼容传统 CDN 缓存或某些企业防火墙——它们可能拦截非标准 upgrade 流量
哪些场景该用 WebSocket，哪些不该
判断依据不是“听起来更高级”，而是看通信模式是否满足「持续、双向、低延迟、小包频繁」这四个条件：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 该用：在线协作文档（
quill或prosemirror的 OT 操作同步）、客服系统坐席状态广播、IoT 设备遥测数据上行 - 不该用：用户登录（
POST /login）、获取文章详情（GET /posts/123）、上传头像（multipart/form-data）——这些本质就是单次请求-响应 - 灰色地带：通知中心未读数。若只推“你有 3 条新通知”，用 Server-Sent Events（SSE）更轻量；若还要支持“已读回执”“撤回通知”，才值得上 WebSocket
WebSocket 的真实代价常被低估
它解决了实时性问题，但把复杂度从协议层转移到了工程层：
- 连接管理：需要自己实现重连策略（指数退避）、连接状态同步（避免重复订阅）、心跳检测（
ping/pong帧） - 消息可靠性：协议本身不保证消息必达，业务层要加 ACK、重传、离线缓存逻辑
- 横向扩展难：连接态有状态，不能像 HTTP 那样简单靠负载均衡甩给任意后端实例，需引入 Redis 订阅广播或 sticky session
- 调试困难：浏览器开发者工具里看不到 WebSocket 数据帧内容（Chrome 120+ 才支持部分解码），抓包得用
wireshark或专用代理
真正上线前，务必确认运维链路是否支持长连接透传（尤其是云厂商 SLB、WAF 默认超时 60 秒）、客户端网络是否稳定（移动端切 WiFi/4G 易断连）、降级方案是否可用（比如断连后 fallback 到 SSE 或轮询）。
