SSE长连接异常降级核心是快速识别、及时切换、保障可用：需组合readyState超时、onerror+id事件、多次重连失败三层信号触发；分场景采用暂停请求、服务繁忙提示或低频轮询兜底；同步缓存、增量拉取、探测验证确保状态一致。

SSE 长连接的异常降级处理，核心不是“维持连接”，而是当连接不可靠或已失效时，快速识别、及时切换、保障功能可用。它不追求连接永不中断，而是在断连发生时，用更稳定但低频的机制兜底，让用户感知不到服务中断。

识别连接异常的三层信号

仅靠 onerror 不够，必须组合判断才能准确触发降级：

• readyState === 0 持续超时：创建后 5 秒内未进入 OPEN（即 readyState === 1），说明初始连接失败（DNS、CORS、4xx/5xx 均可能）
• onerror 触发 + 曾成功接收过带 id 的事件：表明连接曾建立，现在是服务端崩溃或网络中断，需启动恢复流程
• 连续多次重连失败（如 ≥3 次）：无论原因，都应停止自动重试，进入降级状态

降级策略要分场景落地

不同异常类型对应不同兜底方式，不能一刀切：

sc-java-to-ts-interface

将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。

下载

• 网络不可达（navigator.onLine === false）：暂停所有 SSE 尝试，UI 显示“⚠️ 当前无网络，请检查连接”，不发起任何 HTTP 请求
• 服务端拒绝（429/503）：解析响应头中的 Retry-After，禁用实时操作入口（如发送按钮置灰），展示“⏳ 服务繁忙，稍后自动恢复”
• 连接反复中断（如 3 次 open 失败）：切换为低频轮询（例如每 30 秒 GET 一次 /api/sse/status），只拉取关键变更，避免持续占用资源

降级期间保持状态一致性

用户看不到连接断了，但数据不能错乱：

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

• 每次收到 SSE 消息，同步更新本地缓存（如 localStorage 或 IndexedDB 中的订单状态、未读数）
• 降级为轮询时，请求带上上次已知的 lastSeenId 或时间戳，服务端返回增量数据，避免全量拉取
• 恢复 SSE 后，先比对本地缓存与服务端最新快照，对差异项做合并或覆盖，确保 UI 状态最终一致

退出降级需主动验证，而非被动等待

不能等下一个 onopen 就认为恢复成功：

• 重建 EventSource 后，在 onopen 回调里立即发一个轻量探测请求（如 fetch('/health')）
• 若探测成功且 3 秒内收到首条有效事件，则启用 SSE；否则继续轮询，最多再试 2 次
• 用户点击“立即重试”按钮时，清空当前轮询计时器，新建 SSE 实例并重置重试计数