websocket断线重连这个事儿，看着不起眼，真到了线上出问题的时候，能把人折腾到怀疑人生。我印象很深的一次是某个消息推送服务上线后，用户反馈“用着用着就收不到通知了，要刷新页面才好”，查了半天发现根本不是业务逻辑的锅，就是连接悄悄断了之后没有任何恢复机制。从那以后我就养成了一个习惯：但凡项目里要用websocket，第一件事不是写业务收发消息，而是先把断线重连这套骨架搭好。这篇东西就把我这些年踩过的坑、沉淀下来的方案和排查思路整理出来，希望对正在被“连接不稳定”困扰的朋友有点帮助。要说清楚断线重连，先得搞清楚一个事实：websocket连接“断掉”这件事，远比你想的频繁，而且大部分时候并不是服务器主动关的，也不是代码写错了，而是网络环境本身在背后做了一个又一个“隐形操作”。理解不了这一点，后面写重连逻辑就会处处被动。1. 先搞清楚连接是怎么断的1.1 正常关闭与会话终结正常情况下，一条websocket连接结束走的是协议规定的关闭握手：一端发Close帧，另一端回Close帧，然后TCP连接才真正拆除。这种关闭是“礼貌”的，双方都知道连接没了，资源可以立刻释放。但在真实场景里，大量断开根本走不到这一步。最常见的是客户端直接断网，比如手机从WiFi切到移动网络、进电梯、过隧道，TCP连接在底层已经死了，可是应用层一无所知——因为TCP是个“假装可靠”的协议，它只有在发送数据收不到ACK时才会意识到链路出问题，如果两端一直不发数据，它会一直傻等下去。这就是很多长连接“看起来活着，实际上已经死了”的根源。另一个常见情况是服务端主动断开但不发Close帧，比如进程崩溃、被kill -9、机房网络抖动导致负载均衡器把连接重置。客户端这边通常只会收到一个TCP RST，表现就是onerror之后紧跟onclose，而且close事件的code往往是1006（Abnormal Closure）。这个1006非常关键，它意味着连接是非正常关闭的，基本可以断定底层链路出了问题，是触发重连的首要信号。1.2 隐形杀手：NAT超时与空闲回收如果说上面那些还算是“看得见”的断开，那NAT超时就是典型的“看不见的杀手”。绝大多数移动端和家庭宽带用户上网都要经过NAT网关，设备出去的公网IP和端口是网关临时映射的。NAT网关会维护一张映射表，但它不会傻傻地一直记住你，每条映射都有一个超时时间。TCP映射的超时通常2到5分钟，UDP更短，有的只有30秒。一旦在超时时间内这条连接上没有任何数据包经过，网关就会默默把映射删掉。对于位于NAT后面的客户端来说，它对这件事完全无感，它还觉得连接好端端的，但外部主动推消息进来时已经找不到路，直接被网关丢弃。这就解释了一个非常典型的线上故障：用户挂着页面不操作，过了一段时间，服务端发消息用户收不到，但页面不刷新的话，页面里的WebSocket状态依然是“open”，一点异常都看不出来。直到用户手动点击某个按钮触发了websocket.send，客户端才在超时后收到错误，这时候onclose才姗姗来迟地触发。明白这个原理，就能理解为什么“心跳机制”不是可选项而是必选项——它不是用来打扰服务器，而是用来告诉链路中的所有设备“这条连接还活着，别删我的映射”。1.3 服务端异常与网络瞬断的判定难点还有一种情况很磨人：网络只是瞬断了几百毫秒，TCP连接实际上没有完全断开，但某些中间设备（比如不规范的代理、负载均衡器）已经把这个连接标记为失效。等网络恢复，客户端如果继续往这条旧连接上发数据，轻则消息丢失，重则直接触发RST断开。这就带来一个判定难点：客户端怎么知道连接“需要重连”还是“可以继续用”？很多人只看onclose事件，只要没触发就认为连接健康。这是不对的，因为TCP的死亡通知延迟非常高，甚至可能永远不通知。真正可靠的办法是结合心跳超时来做“应用层探活”，服务端超过N秒没回心跳响应，就主动判定连接失效，走重连流程。我个人的经验是：把“连接状态”和“可用状态”区分开。连接对象存在不意味着可用，只有“握手成功且最近一次心跳响应在超时窗口内”才算真正可用。这个思路能让很多边界情况变得异常清晰。2. 重连方案的整体设计：先画边界再写代码2.1 状态机是重连逻辑的地基不少同学写重连，就是onclose里面setTimeout再new WebSocket，看起来能跑，但真到复杂场景就乱了：重连正在进行时用户主动关闭页面怎么办？服务端在重连期间返回了500怎么办？多个重连定时器叠加怎么办？所以我强烈建议，动手前先把连接状态机画出来。状态至少应该包括：DISCONNECTED：初始状态，连接从未建立或已彻底放弃CONNECTING：正在建立连接CONNECTED：已连接且心跳正常RECONNECTING：正在等待退避计时器触发下一次重连CLOSED_BY_USER：用户主动关闭，任何情况下都不得自动重连所有状态迁移必须是单向且明确的。尤其要警惕两个坑：一是RECONNECTING状态下计时器还没到，结果页面又触发了新的重连调用，产生两个并发连接；二是用户主动关闭的意图被淹没在异常关闭里，导致关了页面还在后台无限重连。解决并发重连的办法很笨但很有效：在状态机里加一个原子判断，只有当前状态是DISCONNECTED或RECONNECTING时才允许发起新连接，否则直接return。另外用token校验法，每次打开新连接时生成一个自增id，连接回调触发时先校验id是不是当前最新的，不是就直接忽略，这个办法可以防住“旧连接的异步事件干扰新连接状态”的经典bug。2.2 四项关键参数：间隔、倍率、抖动与上限重连策略不是拍脑袋定个“3秒一次”，这四个参数是需要根据业务场景认真算的：基础间隔（baseDelay）：第一次重连前的等待时间。实时性要求高的场景可以设500ms到1s，要求不高的设2s到5s。太短会放大抖动，太长会让用户明显感到“失联”。倍率（multiplier）：每次重连失败后，间隔乘以多少。常见的是2倍，也就是1s、2s、4s、8s这样翻。翻得太快会让恢复窗口变长，翻得太慢又会在网络长时间不可用时产生大量无效请求。抖动（jitter）：给间隔加一个随机扰动。网络重连最怕“共振”，比如服务端重启后，几万个客户端同时重连，如果间隔都一样，会在同一秒打出几万个连接请求。加抖动，就是在基础间隔上随机增减一部分，让请求分散开。最大间隔（maxDelay）：间隔不能无限翻倍，超过比如30s或60s就封顶，保持恒定频率继续尝试。这里给一个我常用的校准公式：delay = min(maxDelay, baseDelay * Math.pow(multiplier, retryCount)) jitteredDelay = delay / 2 + Math.random() * delay / 2用jitteredDelay作为实际等待时间。注意抖动范围是“一半到全部”，不是“0到全部”，这样既能分散请求，又不会出现某个重连间隔短到0导致瞬间重试。还有一个容易忘的参数是最大重试次数的处理逻辑。断网时间长了，无限重连不仅耗电、耗流量，还会给服务端持续的连接压力。我的做法是：连续失败达到上限（比如10次）后，不再自动重连，而是把状态置为DISCONNECTED并通知业务层显示“连接已断开，点击重试”之类的交互。如果是移动端App，还可以利用系统网络状态监听（比如网络从无信号恢复时）触发一次即时重连，比傻等定时器体验好得多。2.3 业务逻辑与连接逻辑必须解耦这是我见过最多项目踩坑的地方：把业务消息发送直接写死在websocket的onopen回调里，或者把UI更新逻辑直接塞进onmessage里。结果是连接一断，业务全乱。正确的做法是把连接层封装成一个独立的Transport模块，对外只暴露几个语义清晰的方法：connect()、disconnect()、send(msg)、onMessage(callback)、onStatusChange(callback)。内部怎么重连、怎么心跳、怎么退避，业务层完全不用关心。业务层只关心三件事：连接是否可用（状态回调），消息能不能发（send返回布尔值），来了消息怎么处理（onMessage）。这个边界划清楚之后，很多问题会自然消解。比如页面切后台再切回来，业务层只需要调用transport.checkHealth()，由连接层决定是复用现有连接还是走重连，业务层不需要知道自己到底重连了几次。3. 核心实现：心跳、退避与消息补偿3.1 心跳机制怎么设计才算“有效”心跳是断线重连里最核心的一环，但设计不好就是纯摆设。我见过不少人每15秒发一个ping，服务端根本不做处理，这种心跳只能算“安慰剂”。有效的心跳要满足三个要求：第一，能验证双向通路。客户端给服务端发ping，服务端必须原样回复pong，客户端收到pong才算一次成功。只发不收等于只验证了“客户端能发数据”，服务端到客户端的下行通路是不是通的依然不知道。第二，超时判定要独立于网络请求。心跳超时计时器应该在发出ping的时候启动，收到pong时清除。如果用了浏览器的setInterval，要注意长时间运行后可能出现的timer drift，更稳妥的是每次发送后单独设置一次性的setTimeout，收到响应就清掉。第三，心跳要能区分“真死”和“慢”。网络差的时候，心跳延迟可能超过正常阈值，但连接还没死。所以我一般不把心跳超时直接当成断线，而是采用“容忍N次超时”的策略。比如每15秒发一次ping，若连续2次没收到pong（也就是30秒没有任何下行数据），才判定连接死亡，触发重连。这样既不会在弱网下频繁误判，又能在真死的时候及时感知。服务端的心跳处理也顺手提一句：收到ping就回pong，同时把该连接的最后活跃时间更新。服务端的清理线程定期扫表，把超过“1.5倍心跳间隔 + 容忍次数×心跳间隔”时间的连接直接关闭。比如客户端15秒心跳、容忍2次，那服务端清理阈值就是15 + 2×15 = 45秒，超过45秒没任何消息的连接直接掐掉。3.2 指数退避重连完整实现下面给一个完整的客户端重连实现，我注释写得比较详细，可以直接参考。语言用的是TypeScript风格的JavaScript，在浏览器或者Node环境都能跑：class WebSocketTransport { constructor(url, options = {}) { this.url = url; this.baseDelay = options.baseDelay || 1000; this.multiplier = options.multiplier || 2; this.maxDelay = options.maxDelay || 30000; this.maxRetry = options.maxRetry || 10; this.heartbeatInterval = options.heartbeatInterval || 15000; this.heartbeatTimeout = options.heartbeatTimeout || 10000; this.missedHeartbeatLimit = options.missedHeartbeatLimit || 2; this.status = 'DISCONNECTED'; this.retryCount = 0; this.heartbeatTimer = null; this.heartbeatTimeoutTimer = null; this.reconnectTimer = null; this.missedHeartbeat = 0; this.ws = null; this.connToken = 0; this.messageHandlers = []; this.statusHandlers = []; } connect(manual = false) { if (manual) { this.retryCount = 0; } if (this.status === 'CONNECTING' || this.status === 'CONNECTED') { return; } this.setStatus('CONNECTING'); const token = ++this.connToken; this.ws = new WebSocket(this.url); this.ws.onopen = () => { if (token !== this.connToken) return; this.setStatus('CONNECTED'); this.retryCount = 0; this.missedHeartbeat = 0; this.startHeartbeat(); }; this.ws.onmessage = (evt) => { if (token !== this.connToken) return; this.missedHeartbeat = 0; // 如果收到的是pong，单独识别，其余交给业务handler if (evt.data === '--pong--') { this.clearHeartbeatTimeout(); return; } this.messageHandlers.forEach(handler => handler(evt.data)); }; this.ws.onclose = (evt) => { if (token !== this.connToken) return; this.cleanup(); const isUserClosed = this.closedByUser; if (isUserClosed) { this.setStatus('DISCONNECTED'); return; } // 1006是非正常关闭，1000是正常关闭 // 正常关闭且不是服务端要求的重连，就不自动重连 if (evt.code === 1000 && !this.serverRequireReconnect) { this.setStatus('DISCONNECTED'); return; } this.scheduleReconnect(); }; this.ws.onerror = () => { if (token !== this.connToken) return; // error之后浏览器通常会紧接着触发close // 这里不主动重连，等close统一处理 }; } scheduleReconnect() { if (this.retryCount >= this.maxRetry) { this.setStatus('DISCONNECTED'); return; } this.setStatus('RECONNECTING'); this.retryCount++; const delay = this.calcDelay(); this.reconnectTimer = setTimeout(() => { this.connect(); }, delay); } calcDelay() { const exp = Math.min(this.maxDelay, this.baseDelay * Math.pow(this.multiplier, this.retryCount - 1)); return exp / 2 + Math.random() * exp / 2; } startHeartbeat() { this.heartbeatTimer = setInterval(() => { if (this.status !== 'CONNECTED') return; this.sendRaw('--ping--'); this.clearHeartbeatTimeout(); this.setHeartbeatTimeout(); }, this.heartbeatInterval); } setHeartbeatTimeout() { this.heartbeatTimeoutTimer = setTimeout(() => { this.missedHeartbeat++; if (this.missedHeartbeat >= this.missedHeartbeatLimit) { this.ws.close(); } else { // 再试一次心跳 this.sendRaw('--ping--'); this.setHeartbeatTimeout(); } }, this.heartbeatTimeout); } clearHeartbeatTimeout() { if (this.heartbeatTimeoutTimer) { clearTimeout(this.heartbeatTimeoutTimer); this.heartbeatTimeoutTimer = null; } } sendRaw(data) { if (this.ws && this.status === 'CONNECTED') { this.ws.send(data); } } send(data) { if (this.status !== 'CONNECTED' || !this.ws) { // 可以在断线时返回false，或者进入待发送队列 return false; } this.ws.send(data); return true; } cleanup() { clearInterval(this.heartbeatTimer); this.heartbeatTimer = null; this.clearHeartbeatTimeout(); if (this.ws) { // 防止重复清理触发onclose，先置空 const ws = this.ws; this.ws = null; ws.onclose = null; ws.onmessage = null; ws.onerror = null; ws.close(); } } setStatus(status) { this.status = status; this.statusHandlers.forEach(handler => handler(status)); } onMessage(handler) { this.messageHandlers.push(handler); } onStatusChange(handler) { this.statusHandlers.push(handler); } closeByUser() { this.closedByUser = true; clearTimeout(this.reconnectTimer); this.reconnectTimer = null; this.cleanup(); this.setStatus('DISCONNECTED'); } }这段代码的几个设计点值得说清楚：connToken的存在是为了防止“旧连接的close事件把新连接的状态给覆盖掉”。因为没有token校验的话，如果重连过程中第一个连接迟迟没触发close，第二个连接已经onopen了，这时候第一个连接的close事件到达，会把状态误改为RECONNECTING。心跳超时的处理是“先关连接再依赖close事件重连”。手动调ws.close()会触发onclose，但close事件的code会是1005或1000，如果是1000会被误判为正常关闭而不重连，所以这里有个小坑：如果心跳超时触发了主动关闭，要设置一个标志位强制走重连分支。上面代码简化了这个问题，实际项目里建议加一个reason字段区分关闭来源。服务端要求客户端重连的典型场景是“服务端准备发版”。服务端在关闭前给客户端发一条特殊消息告诉客户端“我要关了，你10秒后重连”，客户端收到后设置serverRequireReconnect = true，主动close并立即安排重连。这个场景不用协议标准里的1001（Going Away）去判断，因为有的浏览器对1001之后的自动重连表现不一致。3.3 重连期间的消息缓冲与幂等处理重连期间业务消息怎么办？这是另一个高频问题。如果只是简单地在send失败时返回false，让业务自己处理，那业务会很痛苦。我的经验是在Transport层增加一个可选的“待发送队列”，连接恢复后自动补发。队列设计要注意三点：一是队列大小必须限制。移动弱网环境下，断网半小时可能堆积上千条消息，全塞内存里不现实。我的做法是默认只保留最近50条，先进先出，超过就丢弃最旧的。二是补发时机要在心跳验证通过之后。onopen只代表TCP握手完成，不代表业务可用，最好等到第一次pong收到后再补发，否则可能消息一发出就断，还得重排。三是补发不等于业务成功。客户端补发了消息，但不代表服务端一定收到了，所以业务层需要配合“消息确认”机制。简单做法是每条消息带一个唯一id，服务端处理完回一个ack，客户端在超时未收到ack时重新补发。配合消息id，客户端在断线期间的补发才能做到幂等——服务端根据id去重，保证重复发送不产生重复业务操作。这一段代码就不贴了，原理比代码重要：消息id + ack确认 + 去重表，三件套缺一不可。4. 常见问题与排查技巧实录4.1 服务端僵尸连接堆积怎么清重连逻辑写得再好，服务端也得配合清理。我见过一个比较极端的现网事故：客户端开了重连，但服务端没有心跳清理逻辑，NAT超时把链路掐断后，TCP连接处于半开状态，服务端认为客户端还在，实际上数据已经发不到了。积攒的连接越来越多，最后服务端连接数打满，新用户连不上，老用户消息收不到，整个推送服务瘫痪。服务端清理的标准姿势就是“读超时扫描”：维护每个连接的最后活跃时间，定时任务每分钟跑一次，把超过阈值的连接主动close。阈值要大于客户端心跳周期，一般取“客户端心跳间隔 × 2 + 30秒”比较稳。比如客户端15秒心跳，服务端阈值设60秒，既不会误杀正常连接，又能及时清掉僵尸。另外服务端别只依赖TCP本身的keepalive，操作系统的TCP keepalive默认需要两个小时才探测一次，对websocket这种场景来说太慢了，必须在应用层做。4.2 防止重连风暴：并发场景的保护前面提到用jitter避免客户端同步重连，但还有一个更容易踩的坑：服务端重启后，如果客户端退避重连间隔已经翻到了很长（比如30秒），服务端恢复后客户端可能还在傻等下一次重连，导致恢复时间被拖长。针对这种情况有两套优化方案。方案一是“服务端广播重连信号”：服务端启动完成后，通过另一个轻量通道（比如轮询接口或推送）向所有客户端广播“我活过来了，快来重连”，客户端收到信号立即重新连，不用等退避计时器。方案二是“客户端网络状态监听”：移动端检测到网络从断开变恢复时立即触发重连，Web端监听online事件，PC端监听网络状态变化事件。这里特别提醒一下，绝对不要在网络恢复时用“所有客户端同一个固定时间点重连”，那等于自己制造一次重连风暴。如果要广播重连信号，可以让服务端在响应里带一个随机delay，或者客户端收到信号后自己再加一个随机化的短延迟。4.3 浏览器端的兼容与页面生命周期浏览器环境有几个特殊问题值得单独拎出来说。一是WebSocket在页面关闭时并不会触发onclose，因为页面销毁了，代码都没机会执行。所以做埋点统计时要依托服务端主动断开来感知客户端离线，不能依赖客户端上报的close事件。二是页面切后台时，浏览器为了省电会冻结定时器，尤其是移动端Safari和Chrome的后台冻结机制，setInterval在后台可能被大幅延迟甚至暂停。这会导致两个后果：心跳停发、重连计时器不准。后者更隐蔽——页面从后台切回来，之前设定好的重连timer可能已经被冻结了半天，但它一恢复就会立刻执行，在某些实现下会出现“页面一切回来就涌出好几个重连请求”的情况。对策是监听visibilitychange事件，页面可见时主动检查连接健康状态，该重连就立即重连，不可见时暂停自动重连。这样既省电，也避免后台频繁重连的无效消耗。4.4 一次“重连不上”的排查过程复盘最后分享一个我实际排查过的案例，现象是“客户端在网络恢复后偶尔重连不上，要手动刷新页面才正常”，而且只在某个办公网络下必现。排查过程大概是这样：先看客户端日志，发现重连请求发出去后，onclose事件立刻触发，code是1006。这说明握手都没成功，TCP层就被断了。继续看服务端日志，发现服务端根本没收到这些连接请求（没有accept日志），说明请求在中间链路就被拦截了。然后怀疑是某个安全设备做了“新连接速率限制”。因为办公网出口有防火墙，检测到同一客户端快速重连时，会认为这是异常扫描行为，在一定时间窗口内直接丢弃后续的TCP SYN包。而我当时的退避间隔最长只到3秒，连续重试没有封顶，短时间内发出了多个SYN包，触发了防火墙限流。解决办法是把最大重试次数降下来（10次改为5次），同时把最大间隔提高到15秒以上，还加了随机抖动，让SYN包时间分布更“自然”。改完再测，问题消失。这个案例给了一个通用启发：所有“重连不上”的问题，不要只盯应用层，要按“客户端代码 → 服务端日志 → 中间链路”的顺序逐层排查。尤其当客户端报1006但服务端无日志时，基本可以断定问题出在中间链路，这时候再怎么写重连代码都是白搭，得从连接频率、分发模式上找原因。还有个小技巧，排查断线重连问题时，建议在客户端记录一个“连接时间线日志”，把onopen、onclose、心跳超时、重连调度全部打点，带时间戳。这样出问题后看日志，能很快还原出“到底在哪一步断了，重连卡在了哪里”，比瞎猜高效得多。我自己现在写websocket重连，已经固定成一套模板了：先定义状态机，再写心跳和退避，然后封装Transport层，最后配合服务端做清理和幂等。这个套路在好几个项目里验证过，基本能覆盖掉95%以上的断线场景。剩下那5%，往往不是技术问题，而是业务上压根没想清楚“断线之后到底应该怎么办”——是先排队等恢复，还是直接提示用户手动重连？这个决策，只有业务方自己知道答案。
websocket断线重连这个事儿，看着不起眼，真到了线上出问题的时候，能把人折腾到怀疑人生。我印象很深的一次是某个消息推送服务上线后，用户反馈“用着用着就收不到通知了，要刷新页面才好”，查了半天发现根本不是业务逻辑的锅，就是连接悄悄断了之后没有任何恢复机制。从那以后我就养成了一个习惯：但凡项目里要用websocket，第一件事不是写业务收发消息，而是先把断线重连这套骨架搭好。这篇东西就把我这些年踩过的坑、沉淀下来的方案和排查思路整理出来，希望对正在被“连接不稳定”困扰的朋友有点帮助。要说清楚断线重连，先得搞清楚一个事实：websocket连接“断掉”这件事，远比你想的频繁，而且大部分时候并不是服务器主动关的，也不是代码写错了，而是网络环境本身在背后做了一个又一个“隐形操作”。理解不了这一点，后面写重连逻辑就会处处被动。1. 先搞清楚连接是怎么断的1.1 正常关闭与会话终结正常情况下，一条websocket连接结束走的是协议规定的关闭握手：一端发Close帧，另一端回Close帧，然后TCP连接才真正拆除。这种关闭是“礼貌”的，双方都知道连接没了，资源可以立刻释放。但在真实场景里，大量断开根本走不到这一步。最常见的是客户端直接断网，比如手机从WiFi切到移动网络、进电梯、过隧道，TCP连接在底层已经死了，可是应用层一无所知——因为TCP是个“假装可靠”的协议，它只有在发送数据收不到ACK时才会意识到链路出问题，如果两端一直不发数据，它会一直傻等下去。这就是很多长连接“看起来活着，实际上已经死了”的根源。另一个常见情况是服务端主动断开但不发Close帧，比如进程崩溃、被kill -9、机房网络抖动导致负载均衡器把连接重置。客户端这边通常只会收到一个TCP RST，表现就是onerror之后紧跟onclose，而且close事件的code往往是1006（Abnormal Closure）。这个1006非常关键，它意味着连接是非正常关闭的，基本可以断定底层链路出了问题，是触发重连的首要信号。1.2 隐形杀手：NAT超时与空闲回收如果说上面那些还算是“看得见”的断开，那NAT超时就是典型的“看不见的杀手”。绝大多数移动端和家庭宽带用户上网都要经过NAT网关，设备出去的公网IP和端口是网关临时映射的。NAT网关会维护一张映射表，但它不会傻傻地一直记住你，每条映射都有一个超时时间。TCP映射的超时通常2到5分钟，UDP更短，有的只有30秒。一旦在超时时间内这条连接上没有任何数据包经过，网关就会默默把映射删掉。对于位于NAT后面的客户端来说，它对这件事完全无感，它还觉得连接好端端的，但外部主动推消息进来时已经找不到路，直接被网关丢弃。这就解释了一个非常典型的线上故障：用户挂着页面不操作，过了一段时间，服务端发消息用户收不到，但页面不刷新的话，页面里的WebSocket状态依然是“open”，一点异常都看不出来。直到用户手动点击某个按钮触发了websocket.send，客户端才在超时后收到错误，这时候onclose才姗姗来迟地触发。明白这个原理，就能理解为什么“心跳机制”不是可选项而是必选项——它不是用来打扰服务器，而是用来告诉链路中的所有设备“这条连接还活着，别删我的映射”。1.3 服务端异常与网络瞬断的判定难点还有一种情况很磨人：网络只是瞬断了几百毫秒，TCP连接实际上没有完全断开，但某些中间设备（比如不规范的代理、负载均衡器）已经把这个连接标记为失效。等网络恢复，客户端如果继续往这条旧连接上发数据，轻则消息丢失，重则直接触发RST断开。这就带来一个判定难点：客户端怎么知道连接“需要重连”还是“可以继续用”？很多人只看onclose事件，只要没触发就认为连接健康。这是不对的，因为TCP的死亡通知延迟非常高，甚至可能永远不通知。真正可靠的办法是结合心跳超时来做“应用层探活”，服务端超过N秒没回心跳响应，就主动判定连接失效，走重连流程。我个人的经验是：把“连接状态”和“可用状态”区分开。连接对象存在不意味着可用，只有“握手成功且最近一次心跳响应在超时窗口内”才算真正可用。这个思路能让很多边界情况变得异常清晰。2. 重连方案的整体设计：先画边界再写代码2.1 状态机是重连逻辑的地基不少同学写重连，就是onclose里面setTimeout再new WebSocket，看起来能跑，但真到复杂场景就乱了：重连正在进行时用户主动关闭页面怎么办？服务端在重连期间返回了500怎么办？多个重连定时器叠加怎么办？所以我强烈建议，动手前先把连接状态机画出来。状态至少应该包括：DISCONNECTED：初始状态，连接从未建立或已彻底放弃CONNECTING：正在建立连接CONNECTED：已连接且心跳正常RECONNECTING：正在等待退避计时器触发下一次重连CLOSED_BY_USER：用户主动关闭，任何情况下都不得自动重连所有状态迁移必须是单向且明确的。尤其要警惕两个坑：一是RECONNECTING状态下计时器还没到，结果页面又触发了新的重连调用，产生两个并发连接；二是用户主动关闭的意图被淹没在异常关闭里，导致关了页面还在后台无限重连。解决并发重连的办法很笨但很有效：在状态机里加一个原子判断，只有当前状态是DISCONNECTED或RECONNECTING时才允许发起新连接，否则直接return。另外用token校验法，每次打开新连接时生成一个自增id，连接回调触发时先校验id是不是当前最新的，不是就直接忽略，这个办法可以防住“旧连接的异步事件干扰新连接状态”的经典bug。2.2 四项关键参数：间隔、倍率、抖动与上限重连策略不是拍脑袋定个“3秒一次”，这四个参数是需要根据业务场景认真算的：基础间隔（baseDelay）：第一次重连前的等待时间。实时性要求高的场景可以设500ms到1s，要求不高的设2s到5s。太短会放大抖动，太长会让用户明显感到“失联”。倍率（multiplier）：每次重连失败后，间隔乘以多少。常见的是2倍，也就是1s、2s、4s、8s这样翻。翻得太快会让恢复窗口变长，翻得太慢又会在网络长时间不可用时产生大量无效请求。抖动（jitter）：给间隔加一个随机扰动。网络重连最怕“共振”，比如服务端重启后，几万个客户端同时重连，如果间隔都一样，会在同一秒打出几万个连接请求。加抖动，就是在基础间隔上随机增减一部分，让请求分散开。最大间隔（maxDelay）：间隔不能无限翻倍，超过比如30s或60s就封顶，保持恒定频率继续尝试。这里给一个我常用的校准公式：delay = min(maxDelay, baseDelay * Math.pow(multiplier, retryCount)) jitteredDelay = delay / 2 + Math.random() * delay / 2用jitteredDelay作为实际等待时间。注意抖动范围是“一半到全部”，不是“0到全部”，这样既能分散请求，又不会出现某个重连间隔短到0导致瞬间重试。还有一个容易忘的参数是最大重试次数的处理逻辑。断网时间长了，无限重连不仅耗电、耗流量，还会给服务端持续的连接压力。我的做法是：连续失败达到上限（比如10次）后，不再自动重连，而是把状态置为DISCONNECTED并通知业务层显示“连接已断开，点击重试”之类的交互。如果是移动端App，还可以利用系统网络状态监听（比如网络从无信号恢复时）触发一次即时重连，比傻等定时器体验好得多。2.3 业务逻辑与连接逻辑必须解耦这是我见过最多项目踩坑的地方：把业务消息发送直接写死在websocket的onopen回调里，或者把UI更新逻辑直接塞进onmessage里。结果是连接一断，业务全乱。正确的做法是把连接层封装成一个独立的Transport模块，对外只暴露几个语义清晰的方法：connect()、disconnect()、send(msg)、onMessage(callback)、onStatusChange(callback)。内部怎么重连、怎么心跳、怎么退避，业务层完全不用关心。业务层只关心三件事：连接是否可用（状态回调），消息能不能发（send返回布尔值），来了消息怎么处理（onMessage）。这个边界划清楚之后，很多问题会自然消解。比如页面切后台再切回来，业务层只需要调用transport.checkHealth()，由连接层决定是复用现有连接还是走重连，业务层不需要知道自己到底重连了几次。3. 核心实现：心跳、退避与消息补偿3.1 心跳机制怎么设计才算“有效”心跳是断线重连里最核心的一环，但设计不好就是纯摆设。我见过不少人每15秒发一个ping，服务端根本不做处理，这种心跳只能算“安慰剂”。有效的心跳要满足三个要求：第一，能验证双向通路。客户端给服务端发ping，服务端必须原样回复pong，客户端收到pong才算一次成功。只发不收等于只验证了“客户端能发数据”，服务端到客户端的下行通路是不是通的依然不知道。第二，超时判定要独立于网络请求。心跳超时计时器应该在发出ping的时候启动，收到pong时清除。如果用了浏览器的setInterval，要注意长时间运行后可能出现的timer drift，更稳妥的是每次发送后单独设置一次性的setTimeout，收到响应就清掉。第三，心跳要能区分“真死”和“慢”。网络差的时候，心跳延迟可能超过正常阈值，但连接还没死。所以我一般不把心跳超时直接当成断线，而是采用“容忍N次超时”的策略。比如每15秒发一次ping，若连续2次没收到pong（也就是30秒没有任何下行数据），才判定连接死亡，触发重连。这样既不会在弱网下频繁误判，又能在真死的时候及时感知。服务端的心跳处理也顺手提一句：收到ping就回pong，同时把该连接的最后活跃时间更新。服务端的清理线程定期扫表，把超过“1.5倍心跳间隔 + 容忍次数×心跳间隔”时间的连接直接关闭。比如客户端15秒心跳、容忍2次，那服务端清理阈值就是15 + 2×15 = 45秒，超过45秒没任何消息的连接直接掐掉。3.2 指数退避重连完整实现下面给一个完整的客户端重连实现，我注释写得比较详细，可以直接参考。语言用的是TypeScript风格的JavaScript，在浏览器或者Node环境都能跑：class WebSocketTransport { constructor(url, options = {}) { this.url = url; this.baseDelay = options.baseDelay || 1000; this.multiplier = options.multiplier || 2; this.maxDelay = options.maxDelay || 30000; this.maxRetry = options.maxRetry || 10; this.heartbeatInterval = options.heartbeatInterval || 15000; this.heartbeatTimeout = options.heartbeatTimeout || 10000; this.missedHeartbeatLimit = options.missedHeartbeatLimit || 2; this.status = 'DISCONNECTED'; this.retryCount = 0; this.heartbeatTimer = null; this.heartbeatTimeoutTimer = null; this.reconnectTimer = null; this.missedHeartbeat = 0; this.ws = null; this.connToken = 0; this.messageHandlers = []; this.statusHandlers = []; } connect(manual = false) { if (manual) { this.retryCount = 0; } if (this.status === 'CONNECTING' || this.status === 'CONNECTED') { return; } this.setStatus('CONNECTING'); const token = ++this.connToken; this.ws = new WebSocket(this.url); this.ws.onopen = () => { if (token !== this.connToken) return; this.setStatus('CONNECTED'); this.retryCount = 0; this.missedHeartbeat = 0; this.startHeartbeat(); }; this.ws.onmessage = (evt) => { if (token !== this.connToken) return; this.missedHeartbeat = 0; // 如果收到的是pong，单独识别，其余交给业务handler if (evt.data === '--pong--') { this.clearHeartbeatTimeout(); return; } this.messageHandlers.forEach(handler => handler(evt.data)); }; this.ws.onclose = (evt) => { if (token !== this.connToken) return; this.cleanup(); const isUserClosed = this.closedByUser; if (isUserClosed) { this.setStatus('DISCONNECTED'); return; } // 1006是非正常关闭，1000是正常关闭 // 正常关闭且不是服务端要求的重连，就不自动重连 if (evt.code === 1000 && !this.serverRequireReconnect) { this.setStatus('DISCONNECTED'); return; } this.scheduleReconnect(); }; this.ws.onerror = () => { if (token !== this.connToken) return; // error之后浏览器通常会紧接着触发close // 这里不主动重连，等close统一处理 }; } scheduleReconnect() { if (this.retryCount >= this.maxRetry) { this.setStatus('DISCONNECTED'); return; } this.setStatus('RECONNECTING'); this.retryCount++; const delay = this.calcDelay(); this.reconnectTimer = setTimeout(() => { this.connect(); }, delay); } calcDelay() { const exp = Math.min(this.maxDelay, this.baseDelay * Math.pow(this.multiplier, this.retryCount - 1)); return exp / 2 + Math.random() * exp / 2; } startHeartbeat() { this.heartbeatTimer = setInterval(() => { if (this.status !== 'CONNECTED') return; this.sendRaw('--ping--'); this.clearHeartbeatTimeout(); this.setHeartbeatTimeout(); }, this.heartbeatInterval); } setHeartbeatTimeout() { this.heartbeatTimeoutTimer = setTimeout(() => { this.missedHeartbeat++; if (this.missedHeartbeat >= this.missedHeartbeatLimit) { this.ws.close(); } else { // 再试一次心跳 this.sendRaw('--ping--'); this.setHeartbeatTimeout(); } }, this.heartbeatTimeout); } clearHeartbeatTimeout() { if (this.heartbeatTimeoutTimer) { clearTimeout(this.heartbeatTimeoutTimer); this.heartbeatTimeoutTimer = null; } } sendRaw(data) { if (this.ws && this.status === 'CONNECTED') { this.ws.send(data); } } send(data) { if (this.status !== 'CONNECTED' || !this.ws) { // 可以在断线时返回false，或者进入待发送队列 return false; } this.ws.send(data); return true; } cleanup() { clearInterval(this.heartbeatTimer); this.heartbeatTimer = null; this.clearHeartbeatTimeout(); if (this.ws) { // 防止重复清理触发onclose，先置空 const ws = this.ws; this.ws = null; ws.onclose = null; ws.onmessage = null; ws.onerror = null; ws.close(); } } setStatus(status) { this.status = status; this.statusHandlers.forEach(handler => handler(status)); } onMessage(handler) { this.messageHandlers.push(handler); } onStatusChange(handler) { this.statusHandlers.push(handler); } closeByUser() { this.closedByUser = true; clearTimeout(this.reconnectTimer); this.reconnectTimer = null; this.cleanup(); this.setStatus('DISCONNECTED'); } }这段代码的几个设计点值得说清楚：connToken的存在是为了防止“旧连接的close事件把新连接的状态给覆盖掉”。因为没有token校验的话，如果重连过程中第一个连接迟迟没触发close，第二个连接已经onopen了，这时候第一个连接的close事件到达，会把状态误改为RECONNECTING。心跳超时的处理是“先关连接再依赖close事件重连”。手动调ws.close()会触发onclose，但close事件的code会是1005或1000，如果是1000会被误判为正常关闭而不重连，所以这里有个小坑：如果心跳超时触发了主动关闭，要设置一个标志位强制走重连分支。上面代码简化了这个问题，实际项目里建议加一个reason字段区分关闭来源。服务端要求客户端重连的典型场景是“服务端准备发版”。服务端在关闭前给客户端发一条特殊消息告诉客户端“我要关了，你10秒后重连”，客户端收到后设置serverRequireReconnect = true，主动close并立即安排重连。这个场景不用协议标准里的1001（Going Away）去判断，因为有的浏览器对1001之后的自动重连表现不一致。3.3 重连期间的消息缓冲与幂等处理重连期间业务消息怎么办？这是另一个高频问题。如果只是简单地在send失败时返回false，让业务自己处理，那业务会很痛苦。我的经验是在Transport层增加一个可选的“待发送队列”，连接恢复后自动补发。队列设计要注意三点：一是队列大小必须限制。移动弱网环境下，断网半小时可能堆积上千条消息，全塞内存里不现实。我的做法是默认只保留最近50条，先进先出，超过就丢弃最旧的。二是补发时机要在心跳验证通过之后。onopen只代表TCP握手完成，不代表业务可用，最好等到第一次pong收到后再补发，否则可能消息一发出就断，还得重排。三是补发不等于业务成功。客户端补发了消息，但不代表服务端一定收到了，所以业务层需要配合“消息确认”机制。简单做法是每条消息带一个唯一id，服务端处理完回一个ack，客户端在超时未收到ack时重新补发。配合消息id，客户端在断线期间的补发才能做到幂等——服务端根据id去重，保证重复发送不产生重复业务操作。这一段代码就不贴了，原理比代码重要：消息id + ack确认 + 去重表，三件套缺一不可。4. 常见问题与排查技巧实录4.1 服务端僵尸连接堆积怎么清重连逻辑写得再好，服务端也得配合清理。我见过一个比较极端的现网事故：客户端开了重连，但服务端没有心跳清理逻辑，NAT超时把链路掐断后，TCP连接处于半开状态，服务端认为客户端还在，实际上数据已经发不到了。积攒的连接越来越多，最后服务端连接数打满，新用户连不上，老用户消息收不到，整个推送服务瘫痪。服务端清理的标准姿势就是“读超时扫描”：维护每个连接的最后活跃时间，定时任务每分钟跑一次，把超过阈值的连接主动close。阈值要大于客户端心跳周期，一般取“客户端心跳间隔 × 2 + 30秒”比较稳。比如客户端15秒心跳，服务端阈值设60秒，既不会误杀正常连接，又能及时清掉僵尸。另外服务端别只依赖TCP本身的keepalive，操作系统的TCP keepalive默认需要两个小时才探测一次，对websocket这种场景来说太慢了，必须在应用层做。4.2 防止重连风暴：并发场景的保护前面提到用jitter避免客户端同步重连，但还有一个更容易踩的坑：服务端重启后，如果客户端退避重连间隔已经翻到了很长（比如30秒），服务端恢复后客户端可能还在傻等下一次重连，导致恢复时间被拖长。针对这种情况有两套优化方案。方案一是“服务端广播重连信号”：服务端启动完成后，通过另一个轻量通道（比如轮询接口或推送）向所有客户端广播“我活过来了，快来重连”，客户端收到信号立即重新连，不用等退避计时器。方案二是“客户端网络状态监听”：移动端检测到网络从断开变恢复时立即触发重连，Web端监听online事件，PC端监听网络状态变化事件。这里特别提醒一下，绝对不要在网络恢复时用“所有客户端同一个固定时间点重连”，那等于自己制造一次重连风暴。如果要广播重连信号，可以让服务端在响应里带一个随机delay，或者客户端收到信号后自己再加一个随机化的短延迟。4.3 浏览器端的兼容与页面生命周期浏览器环境有几个特殊问题值得单独拎出来说。一是WebSocket在页面关闭时并不会触发onclose，因为页面销毁了，代码都没机会执行。所以做埋点统计时要依托服务端主动断开来感知客户端离线，不能依赖客户端上报的close事件。二是页面切后台时，浏览器为了省电会冻结定时器，尤其是移动端Safari和Chrome的后台冻结机制，setInterval在后台可能被大幅延迟甚至暂停。这会导致两个后果：心跳停发、重连计时器不准。后者更隐蔽——页面从后台切回来，之前设定好的重连timer可能已经被冻结了半天，但它一恢复就会立刻执行，在某些实现下会出现“页面一切回来就涌出好几个重连请求”的情况。对策是监听visibilitychange事件，页面可见时主动检查连接健康状态，该重连就立即重连，不可见时暂停自动重连。这样既省电，也避免后台频繁重连的无效消耗。4.4 一次“重连不上”的排查过程复盘最后分享一个我实际排查过的案例，现象是“客户端在网络恢复后偶尔重连不上，要手动刷新页面才正常”，而且只在某个办公网络下必现。排查过程大概是这样：先看客户端日志，发现重连请求发出去后，onclose事件立刻触发，code是1006。这说明握手都没成功，TCP层就被断了。继续看服务端日志，发现服务端根本没收到这些连接请求（没有accept日志），说明请求在中间链路就被拦截了。然后怀疑是某个安全设备做了“新连接速率限制”。因为办公网出口有防火墙，检测到同一客户端快速重连时，会认为这是异常扫描行为，在一定时间窗口内直接丢弃后续的TCP SYN包。而我当时的退避间隔最长只到3秒，连续重试没有封顶，短时间内发出了多个SYN包，触发了防火墙限流。解决办法是把最大重试次数降下来（10次改为5次），同时把最大间隔提高到15秒以上，还加了随机抖动，让SYN包时间分布更“自然”。改完再测，问题消失。这个案例给了一个通用启发：所有“重连不上”的问题，不要只盯应用层，要按“客户端代码 → 服务端日志 → 中间链路”的顺序逐层排查。尤其当客户端报1006但服务端无日志时，基本可以断定问题出在中间链路，这时候再怎么写重连代码都是白搭，得从连接频率、分发模式上找原因。还有个小技巧，排查断线重连问题时，建议在客户端记录一个“连接时间线日志”，把onopen、onclose、心跳超时、重连调度全部打点，带时间戳。这样出问题后看日志，能很快还原出“到底在哪一步断了，重连卡在了哪里”，比瞎猜高效得多。我自己现在写websocket重连，已经固定成一套模板了：先定义状态机，再写心跳和退避，然后封装Transport层，最后配合服务端做清理和幂等。这个套路在好几个项目里验证过，基本能覆盖掉95%以上的断线场景。剩下那5%，往往不是技术问题，而是业务上压根没想清楚“断线之后到底应该怎么办”——是先排队等恢复，还是直接提示用户手动重连？这个决策，只有业务方自己知道答案。