WebSocket客户端防重连雪崩需采用指数退避叠加随机抖动：起始延迟100–500ms，每次失败后延迟翻倍，上限30秒、最多10次；再乘以[0.5, 1.5)随机因子实现错峰，配合服务端Retry-After、健康检查与多endpoint分流。
WebSocket 客户端在服务器宕机后若统一重连，极易引发“重连雪崩”——大量客户端在同一时刻发起连接请求，压垮刚恢复的服务器。解决核心是让重连时间**分散化、非同步化**，而指数退避（Exponential Backoff）叠加随机抖动（Jitter）正是业界标准方案。
指数退避：让重连间隔逐次拉长
基础思路是每次失败后，将下次重试延迟翻倍（如 1s → 2s → 4s → 8s…），避免短时间密集冲击。但纯指数退避仍存在“同步重试”风险——若所有客户端在同一秒断开，它们将在同一秒重试（比如都卡在第3次重试的4秒点）。
- 起始延迟建议设为 100–500ms，避免首次重连过于激进
- 最大延迟需设上限（如 30 秒），防止等待过久影响用户体验
- 重试次数也应限制（如最多 10 次），失败后可降级提示或切换备用地址
随机抖动：打破时间对齐，实现天然错峰
在指数延迟基础上，乘以一个 [0.5, 1.5) 区间的随机因子（即 ±50% 抖动），让每个客户端的实际重连时间呈均匀分布。例如：第3次重试理论延迟为 4000ms，实际延迟可能是 2100ms 或 5800ms，大幅降低并发峰值概率。
- 抖动范围不宜过大（如超过 ±75%），否则可能削弱退避效果
- 推荐使用
Math.random() * 0.5 + 0.5生成 [0.5, 1.0) 基础因子，再线性扩展为 [0.5, 1.5) - 抖动应在每次重试时重新生成，而非固定值
代码实现要点（客户端）
关键不是“立刻重连”，而是“计划重连”。用 setTimeout 控制延迟，每次断开（onclose）时清除旧定时器并启动新定时器：
立即学习“Java免费学习笔记（深入）”；
- 维护重试计数器和当前延迟值，断开时递增计数器
- 计算延迟：
delay = Math.min(base * Math.pow(2, attempt), maxDelay) - 加入抖动：
delay = delay * (Math.random() * 1.0 + 0.5)（即 [0.5, 1.5)） - 调用
setTimeout(() => this.connect(), delay)启动下一次连接 - 成功连接后重置计数器；手动关闭（如页面卸载）时清空定时器
增强稳定性的小技巧
单纯靠客户端算法还不够，服务端和网络层配合能进一步缓解压力：
- 服务端可返回
Retry-AfterHTTP Header（适用于 WebSocket 升级前的握手阶段），引导客户端按服务端建议延迟 - 客户端可记录最近几次重连耗时与失败原因（如超时 vs 连接拒绝），动态调整初始 base 值
- 引入简单健康检查（如先发 HTTP GET /health），确认服务基本可用后再建 WebSocket，减少无效连接尝试
- 若部署多可用区，客户端可轮询或按地域就近选择备用 endpoint，分流压力
