前端面试：如何设计可靠的 WebSocket 断线重连客户端？

题干与适用场景

题目考察前端工程师能否把 WebSocket 当成不可靠连接来管理。浏览器可能经历 Wi-Fi 切换、休眠、代理断开、服务端重启或静默半开连接；只在 onclose 中立刻 connect() 会制造重连风暴，也无法找回断线期间的事件。回答应覆盖客户端状态、退避、心跳、补偿同步、鉴权和页面生命周期。

面试官考察点

强回答会先定义消息语义和恢复边界，再用显式状态机约束连接转换。它会使用随机抖动的指数退避、应用层心跳检测半开连接、序列号或游标补拉缺失事件，并让发送队列区分可丢弃与必须确认的消息。还应说明后台标签页、网络变化、token 过期、服务端限流和用户可见状态。

回答前需要澄清的问题

• 消息是可丢失通知、可重放事件，还是必须一次处理的命令？服务端是否提供游标补拉？
• 连接鉴权如何刷新？重连时 token 过期、权限变化或协议版本变化怎么办？
• 心跳由谁发送和确认？代理可能静默丢包多久，允许多长检测时间？
• 需要支持多标签页、移动端后台、浏览器休眠和网络从在线到离线吗？
• 重连期间用户可以继续编辑吗？冲突、顺序和重复提交如何处理？

30 秒回答框架

“我会把客户端建模成 idle、connecting、open、suspect、backoff、closed 六态。打开后使用带超时的应用层 ping/pong，异常关闭或心跳超时进入指数退避并加入随机抖动，避免所有客户端同时重连。每条事件带递增序列号，重连成功先用 last-seen 游标补拉，再开放实时消费；命令采用幂等键和确认，通知可以丢弃。页面隐藏、离线和 token 过期时暂停或重新鉴权，并向用户显示明确的连接状态。”

分步骤深入解答

第一步：定义连接状态机

不要让多个回调分别修改 isConnected。集中定义状态和合法转换，例如 connecting -> open -> suspect -> backoff -> connecting；用户主动关闭进入 closed，不再自动重连。每次转换记录原因、尝试次数和连接 id，便于诊断重复连接。

第二步：区分 close、error 与半开

浏览器的 error 不一定提供可操作原因，close 也可能长时间不触发。应用层心跳需要记录发送时间、pong deadline 和最近收到的消息；超时后主动关闭旧 socket，再进入退避。不要同时保留旧连接和新连接，否则会产生重复事件。

第三步：实现退避与抖动

RFC 6455 警告客户端持续立即重连会形成拒绝服务式重连风暴。可用 min(cap, base * 2^attempt) + random(0, jitter) 计算延迟；成功稳定一段时间后重置次数。服务端返回明确的限流或维护提示时，应尊重 Retry-After 或更长冷却时间。

第四步：恢复事件游标

实时事件必须带单调递增的 stream sequence。客户端持久化最后连续处理的序号，重连握手携带该游标；服务端先返回缺失区间，再切换到实时流。若游标过期，服务端返回快照版本，客户端加载快照并从快照后的序号继续。

第五步：设计发送队列与幂等

把消息分为 presence、typing 等可丢弃通知，以及编辑、支付意图等必须确认的命令。命令携带 clientMessageId，服务端按幂等键去重并返回结果；断线期间只缓存有界队列，超过上限时阻止继续提交并提示用户，不把无限队列藏在内存里。

第六步：处理鉴权与协议变化

重连前检查 token 是否即将过期，必要时先刷新；收到未授权关闭码时停止盲目重试并进入重新登录流程。握手携带协议版本，服务端不兼容时降级到兼容版本或提示升级，不能让客户端在错误版本上循环重连。

第七步：结合页面与网络生命周期

visibilitychange、online/offline 和移动端后台都会改变连接策略。后台页面可降低心跳频率或暂停实时流，回到前台后执行一次健康检查与游标同步。离线时立即停止拨号，网络恢复后再按退避启动，避免浏览器反复失败。

第八步：监控用户体验和服务端压力

客户端记录连接建立耗时、重连次数、心跳超时、补拉事件数、游标缺口和队列丢弃数；服务端按租户和版本观察并发连接、握手失败、重连峰值与重复消息。错误日志不能包含 token 或消息正文。用户看到“正在重连”“已同步到最新”比看到技术错误码更有帮助。

一个最小状态机伪代码

on_open(socket):
    state = OPEN
    send({type: "resume", lastSeen: cursor})

on_heartbeat_timeout():
    socket.close()
    state = BACKOFF
    delay = min(MAX, BASE * 2 ** attempts) + random(0, JITTER)
    schedule(connect, delay)

on_resume_complete(newCursor):
    cursor = newCursor
    state = OPEN
    attempts = 0

设计取舍与边界

WebSocket 本身只提供有序字节消息，不自动提供业务级 exactly-once、离线队列或状态同步。可靠性必须由协议层定义；如果业务只需要服务端推送且可接受丢失，也可以比较 SSE，但不能在面试中把传输协议替代成恢复语义。

落地计划与证据

先实现状态机、心跳和带抖动退避，再增加游标恢复和幂等命令。用网络切换、服务端重启、浏览器休眠、token 过期和 1000 个客户端同时断线做演练。RFC 6455 明确建议异常关闭后采用随机初始延迟和逐步增加的退避；MDN 的 WebSocket API 文档可作为浏览器事件和 readyState 的实现依据。

试点的退出条件

断线后无需刷新即可恢复；恢复后没有重复或缺失的已确认命令；重连峰值不会压垮服务端；后台页面不持续占用连接；用户能看到当前状态和最后同步时间。任何一项不满足，先修复协议或生命周期策略。

怎样证明收益不是巧合

比较改造前后的恢复成功率、p95 恢复时间、重复事件率、游标缺口、服务端握手峰值和移动端耗电。按网络类型、浏览器版本和页面可见性分层，避免平均值掩盖某一平台的失败。

常见误区与追问

在 onclose 里立即重连

服务端重启时所有客户端会同时拨号，形成 thundering herd。必须使用退避、抖动和服务端限流提示，并在稳定连接后重置尝试次数。

只依赖 close 事件

半开连接可能没有 close。用应用层心跳和 deadline 主动判定失联，再关闭旧 socket 并重建连接。

重连成功就认为数据完整

连接恢复不代表断线期间事件已到达。通过 last-seen 游标补拉、快照版本和连续序号验证完整性。

如何避免重复命令？

每个命令使用客户端生成的幂等键，服务端持久化处理结果；客户端只在收到确认或查询到结果后移除队列项。

token 在重连时过期怎么办？

先刷新并重新握手；明确未授权关闭码时停止重试，转入登录流程。不要把鉴权失败当成网络抖动。

多标签页如何控制连接数？

可用 BroadcastChannel 或 SharedWorker 选举一个拥有连接的 tab，其余 tab 订阅事件；页面关闭或 owner 失联时再转移所有权，并保留游标校验。