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
- 对高频事件（如进度条更新），可用节流或只保留最新一条，避免频繁触发渲染
状态管理侧支持被动接收 + 主动响应
仅靠推送无法触发页面级行为（如滚动到底部、弹窗提醒），状态管理需预留副作用入口：
立即学习“Java免费学习笔记（深入）”；
- 在 store 中定义带副作用的 action，例如 onNewMessage(msg)，内部既更新消息列表，也调用 scrollIntoView()
- 利用 Zustand 的 subscribe、Pinia 的 $onAction 或 Redux 中间件捕获特定事件类型，分离数据更新与 UI 副作用
- 对需乐观更新的操作（如“发送中”状态），先本地变更，等 SSE 返回确认事件后再修正，避免状态漂移
暴露连接健康状态，让 UI 可感知
SSE 自动重连是默认行为，但用户需要知道当前是否可靠在线：
- 维护 connectionStatus: 'idle' | 'connecting' | 'connected' | 'failed'，并附带重试次数、最后失败时间等元信息
- 当连续重连失败（如超 5 次），触发降级逻辑：切换为轮询、显示离线提示、冻结发布按钮等
- 所有 API 请求拦截器中检查该状态，若为 failed 或 connecting，可暂缓非关键请求，避免雪崩
