SSE 最好和状态管理打通来完成数据同步：通过封装 EventSource 单例把连接统一管理起来，收到推送数据后先完成解析，再交给 store 接手；同时还要支持副作用响应，并把连接健康状态对外暴露出来，让 UI 能及时感知，必要时还能平稳降级。

SSE 和状态管理库一起用时，重点不在于“收到什么就一股脑塞进 store”。真正重要的是，让事件流、连接生命周期、状态更新这三件事彼此对上节奏，顺着同一条逻辑走。

SSE 负责稳定接收消息，并把推送逻辑从业务里拆开。状态管理则负责用响应式方式驱动 UI，同时把更新路径维持在可追踪、可预测的范围内。

封装 EventSource 实例，统一管理连接

不要在多个组件中各自 new EventSource。这样很容易引发重复连接、内存泄漏或状态不同步问题。

更合适的做法是，将其封装为带控制能力的单例或模块，统一处理连接与分发逻辑。

• 连接建立后，统一监听 message 或自定义事件（如 update、progress），再分发给对应状态模块
• 将 readyState 同步到全局状态（如 isConnected: boolean），供 UI 显示“重连中”“已断开”等提示
• 组件卸载时主动调用 es.close() 并清理监听器，防止 React/Vue 中 setState 或 store 更新触发在已销毁实例上

消息解析与状态更新解耦

SSE 推送的是纯文本 data 字段，因此应先完成安全解析，再交由状态管理处理。不建议在 onmessage 里直接 dispatch。

• 先校验 JSON 格式、过滤空/重复数据、提取 id 或时间戳用于去重或排序
• 把解析逻辑抽成纯函数，例如 parseNotification(raw): NotificationItem，再传给 store 的 action
• 对高频事件（如进度条更新），可用节流或只保留最新一条，避免频繁触发渲染

状态管理侧支持被动接收与主动响应

仅靠推送，通常无法触发页面级行为，例如滚动到底部、弹窗提醒。为此，状态管理层需要预留副作用入口。

• 在 store 中定义带副作用的 action，例如 onNewMessage(msg)，内部既更新消息列表，也调用 scrollIntoView()
• 利用 Zustand 的 subscribe、Pinia 的 $onAction 或 Redux 中间件捕获特定事件类型，分离数据更新与 UI 副作用
• 对需乐观更新的操作（如“发送中”状态），先本地变更，等 SSE 返回确认事件后再修正，避免状态漂移

暴露连接健康状态，让 UI 可感知

SSE 自动重连是默认行为，但用户仍需要知道当前连接是否可靠在线。因此，连接状态应对外暴露，并纳入统一状态管理。

• 维护 connectionStatus: 'idle' | 'connecting' | 'connected' | 'failed'，并附带重试次数、最后失败时间等元信息
• 当连续重连失败（如超 5 次），触发降级逻辑：切换为轮询、显示离线提示、冻结发布按钮等
• 所有 API 请求拦截器中检查该状态，若为 failed 或 connecting，可暂缓非关键请求，避免雪崩

核心原则

SSE 负责接收，store 负责承接，UI 负责感知。这三部分只有协同起来，数据同步才会稳定、清晰且可维护。

因此，实践中应优先做好三件事：统一连接管理、解析后再更新状态、把连接健康状态明确暴露给界面。这样才能在正常推送、异常重连和降级切换之间保持一致的行为表现。

《夸克》非常好用的免费AI浏览器

下载APP查看