WebSocket是实现抢购排队人数实时显示的理想技术，因其建立持久双向连接，可毫秒级推送队列位置、库存等信息，避免AJAX轮询的延迟、资源浪费与状态丢失问题。
WebSocket 是实现抢购活动中“排队人数实时显示”的理想技术，它能建立浏览器与服务器之间的持久双向连接，避免轮询带来的延迟和资源浪费。
为什么用 WebSocket 而不是 AJAX 轮询
抢购场景对实时性要求极高：用户进入队列、位置变动、队列释放都需毫秒级同步。传统 AJAX 轮询存在明显缺陷：
- 频繁请求增加服务器压力，尤其在高并发下易引发雪崩
- 固定间隔（如1秒）导致数据滞后——可能错过关键状态跳变（如从“排队中第127位”直接变为“已获得购买资格”）
- 无服务端主动推送能力，客户端只能被动等待下一次请求
WebSocket 建立单条长连接后，服务端可在任意时刻将最新排队序号、剩余库存、倒计时等信息精准推送给指定用户，延迟通常控制在 50ms 内。
前端关键实现要点
初始化连接后，需监听消息并安全更新 UI，同时处理异常重连：
立即学习“前端免费学习笔记（深入）”；
- 连接成功后立即发送用户身份标识（如 userId 或临时 token），便于服务端关联排队上下文
- 监听
message事件，解析 JSON 数据（如{ "type": "queue_update", "position": 42, "total": 1280 }），用 innerText 或 textContent 更新 DOM，避免 innerHTML 防 XSS - 监听
onerror和onclose，触发自动重连（建议指数退避：1s → 2s → 4s → 最大 30s），并显示“连接中…”提示 - 用户切页或失焦时调用
ws.close()，恢复时重建连接，防止无效连接堆积
后端需配合的状态管理逻辑
WebSocket 本身不解决业务状态一致性，需结合后端队列模型：
- 用户点击“加入抢购”时，先通过 HTTP 接口提交请求，服务端将其写入有序队列（如 Redis Sorted Set），返回初始位置，并通过 WebSocket 主动推送该位置
- 当库存释放（如超时用户被踢出、支付失败回滚），服务端按顺序激活下一个用户，同时向其 WebSocket 连接推送
{"type":"granted"}，并广播新队首位置给其余用户 - 为防重复推送，每个连接应绑定唯一 session ID，服务端维护“连接ID ↔ 用户ID ↔ 队列位置”映射表
真实场景中的降级与兜底
即使使用 WebSocket，也要考虑弱网、代理中断等现实问题：
- 首次加载页面时，用一次 HTTP 请求获取当前排队概况（如“当前已有 9321 人排队”），作为 WebSocket 连接建立前的可信快照
- 若连续 3 次收不到服务端心跳（如每 15 秒发 ping），前端主动断开并切换至 3 秒间隔的短轮询，直到 WebSocket 恢复
- 在 UI 显示“实时”字样旁加小图标，连接正常时为绿色实心圆，异常时为黄色空心三角，提升用户感知透明度
