前端应明确提示sse断连并手动控制重连:监听error事件,结合readystate和ismanuallyclosed判断异常断连;用轻量toast显示“正在恢复”,禁用默认重连,延迟递增重建连接;离线时暂停重连,并保持ui状态一致性。

当SSE(Server-Sent Events)连接意外断开时,前端应避免静默重连,而是通过UI明确告知用户“连接已断开,正在尝试恢复”,同时保持状态可感知、不干扰操作、支持手动重试。关键在于结合EventSource的原生事件、合理的重连策略和轻量级UI反馈。
监听 error 事件并区分断连类型
EventSource 的 error 事件会在连接关闭、网络失败或服务端返回非2xx响应时触发,但它**不区分是主动关闭还是异常中断**。你需要结合 readyState 和简单状态标记来判断是否属于“需提示的异常断连”:
- 如果
eventSource.readyState === 0(即EventSource.CLOSED),且不是你主动调用close()关闭的,就视为异常断连 - 若
readyState === 0但之前从未成功连接过(如首次打开页面就失败),可显示“连接中…”而非“恢复中”,避免误导 - 建议加一个
isManuallyClosed标志位,调用close()前设为true,在error回调里跳过提示
用轻量Toast或状态栏提示“正在恢复”
避免弹窗或遮罩层打断用户,推荐使用底部/顶部固定状态条或右上角非阻塞Toast:
你接手一个需求时,是不是经常这样:"改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续";这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境(JDK、Spring Boot、ORM、数据库、前端框架),记在
- 初始提示文案:“⚠️ 网络连接不稳定,正在尝试重新连接…”(带图标+省略号增强动态感)
- 连接恢复后自动消失,并显示1秒绿色提示:“✅ 已恢复连接”(可选)
- 若连续3次重连失败(例如5秒间隔×3),升级提示为:“❌ 无法连接服务器,请检查网络或稍后重试”,并显示“重试”按钮
- 按钮点击后调用
new EventSource(...)并重置重试计数器
控制重连节奏,避免界面频繁闪烁
浏览器默认会在连接失败后约3秒自动重连,但这个行为不可控且无反馈。建议禁用默认重连,手动管理:
- 创建
EventSource时设置withCredentials: true(如需鉴权),并**不设置retry字段**,防止服务端控制重连逻辑与前端UI脱节 - 在
error回调中清除旧实例,延迟(如2–5秒)后新建——延迟时间可随失败次数递增(2s → 4s → 8s),避免雪崩请求 - 每次新建前检查
navigator.onLine,若为false,暂停自动重连,只显示“⚠️ 检测到离线状态,已暂停重连…”
保持业务数据状态一致性
提示“正在恢复”不只是UI动作,更要让功能感知连接状态:
- 禁用依赖实时数据的操作按钮(如“刷新列表”、“发送消息”),添加
disabled和title="等待连接恢复" - 对已缓存的最后一条SSE数据,可保留展示并加灰色小字标注“(最后更新:2分钟前)”
- 若SSE承载的是通知类消息,断连期间新消息应暂存内存(不超过10条),恢复后按序补推(需服务端配合或前端模拟时间戳去重)
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










