websocket用于解决实时协作等场景的高延迟与资源浪费问题，如在线编辑中替代轮询实现服务端主动推送；握手需校验sec-websocket-accept，反向代理须透传upgrade头；发送前检查readystate与bufferedamount，onmessage用addeventlistener注册；心跳用原生ping/pong，重连按code区分并指数退避。

面试官问 WebSocket，不是要你背定义，而是想听你讲清楚“为什么用它、怎么用稳、出问题怎么兜住”这三层逻辑。答得准，比答得多更重要。

紧扣场景说清“为什么非用不可”

别一开口就说“全双工、实时、长连接”。直接举一个真实痛点：

• 比如在线协作编辑：如果用 HTTP 轮询，用户每敲一个字都要发请求查有没有别人改过，延迟高、服务器压力大；而 WebSocket 让服务端在有人修改时立刻推变更，客户端只管接收和合并，体验和资源消耗天差地别
• 再补一句对比：“短轮询是每2秒白问一次，长轮询是每次都要重走 HTTP 头、Cookie、TLS 握手；WebSocket 握一次手，后面所有消息只有 2–14 字节帧头，没冗余开销”

握手过程讲到关键校验点

握手本质是 HTTP 升级协商，但必须点出两个易错细节：

dmap-jsapi-skill

DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。

下载

• 客户端发 GET 请求，带 Upgrade: websocket 和 Sec-WebSocket-Key（随机 base64）；服务端必须返回 HTTP/1.1 101 Switching Protocols，且 Sec-WebSocket-Accept 是对 Key 拼固定字符串后 SHA-1 base64 的结果——这个值校验失败，连接当场断在握手阶段
• Nginx 等反向代理常导致握手失败，因为默认不透传 Upgrade 和 Connection 头，必须显式配置：proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade";

连接管理不能只看 readyState

readyState === 1（OPEN）只是连接就绪，不代表 send() 一定成功：

• send 前务必写 if (ws.readyState === WebSocket.OPEN)，别用魔法数字 1
• 真正判断发送是否卡住，要看 ws.bufferedAmount：持续上涨说明数据压在发送队列里，可能是网络抖动或服务端写缓冲满，此时重连无效，该降频或等恢复
• onmessage 别反复赋值：ws.onmessage = handler 会覆盖前一个；要用 addEventListener('message', handler)，组件卸载时记得 removeEventListener

心跳与重连要体现工程思维

光说“定时发 ping”不够，得讲设计取舍：

• 心跳建议用 WebSocket 原生 Ping/Pong 帧（服务端自动响应），比自定义消息更轻量、不占业务通道
• 断线重连必须检查 event.wasClean 和 event.code：code=1000 是正常关闭，不用重连；code=1006 是异常断开，才触发重试
• 重试间隔用指数退避（1s → 2s → 4s → 8s…），并设最大重试次数（如 5 次），避免雪崩；连续失败可降级为 SSE 或轮询保底