客户端不加退避重连会引发重连风暴，导致服务端连接数爆满、端口耗尽、Redis/MySQL拒绝连接；指数退避通过指数增长、随机抖动、上限约束三重机制打散请求，前端必须主动实现，后端限流仅为兜底。

因为不加退避的重连会直接压垮服务端，哪怕Workerman本身再健壮也扛不住“重连风暴”。

客户端扎堆重连时，服务端实际发生了什么

网络闪断（比如运营商切换、Wi-Fi掉线）往往不是单个用户的事，而是成片发生。前端若用固定间隔（如每1秒重连一次），数万设备会在几乎同一毫秒发起连接请求：

• onConnect 回调被密集触发，所有 Worker 进程同时执行业务初始化逻辑
• 如果业务里有 new Redis() 或 new PDO()，瞬间创建海量 TCP 连接，打满本地端口池，触发 Cannot assign requested address
• Redis 服务器收到超限连接请求，返回 ERR max number of clients reached
• MySQL 可能因连接数爆满拒绝新连接，或触发 Too many connections
• 即使连接成功，后续 onMessage 处理也会因资源争抢而延迟飙升

指数退避为什么能破局

它不是单纯“拉长等待时间”，而是通过三重机制打散压力：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

• 指数增长：第1次等 1000ms，第2次等 2000ms，第3次等 4000ms……让重连请求随时间自然稀疏化
• 随机抖动：在每次计算出的间隔上叠加 ±30% 随机偏移（如 4000 * (0.7 + Math.random() * 0.6)），彻底打破同步重连节奏
• 上限约束：设 maxReconnectDelay = 30000，避免长期失联设备无限拉长重试窗口，影响监控与故障定位

Workerman 侧无法替代客户端退避

服务端能做的限流（如 limit_conn、IP 计数拦截）只是兜底，本质是“丢弃请求”；而客户端退避是“主动错峰”，效果差一个数量级：

立即学习“前端免费学习笔记（深入）”；

• 网关层限流会把合法重连也拦掉，导致部分用户永远连不上
• Redis 连接池隔离、onWorkerStart 初始化这些 Workerman 优化，只解决“单次连接建立后的稳定性”，不缓解“连接洪峰”本身
• 如果你控制不了客户端（比如第三方硬件设备），那必须在接入层（Nginx / GatewayWorker）补上退避模拟逻辑，不能指望 Workerman 自己消化

真正容易被忽略的是：退避逻辑必须实现在前端代码里，而不是靠后端返回错误再重试——因为第一次 WebSocket 连接失败时，根本没机会收到服务端响应，只能靠客户端自身判断并启动退避计时器。