前端架构SSEWebSocketPolling长任务
前端如何处理长任务：SSE、WebSocket 与轮询的工程选型对比
AI 与 Agent 场景里，长任务反馈链路决定用户体验与系统成本。本文从连接模型、重连语义、一致性策略、网关兼容、移动端表现与运维复杂度六个维度，对比 SSE、WebSocket、Polling 的真实取舍，并给出可执行的选型决策树。
2026年3月5日
Synthly 团队
预计阅读 15 分钟
📷 Photo by Brett Sayles via Pexels
一、长任务通信不是“实时不实时”，而是“一致不一致”
很多团队把问题简化成：
- WebSocket 更实时
- SSE 更简单
- 轮询更土
真正上线后，你会发现核心不是“实时感”，而是“状态一致性”与“恢复能力”：
- 断线后如何补事件？
- 网关超时后如何恢复？
- 移动端后台回来是否能追平进度？
通信方式只是手段，任务状态一致才是目标。
二、三种机制的能力边界
SSE（Server-Sent Events）
适合：服务端单向连续推送（token、步骤进展）
优点：
- 浏览器原生
EventSource - 语义清晰，调试成本低
- 与“流式输出”天然匹配
限制：
- 主要单向通信
- 部分网关/代理默认超时配置敏感
WebSocket
适合：高频双向交互、房间协作、多事件并发
优点：
- 双向低延迟
- 事件类型扩展灵活
限制：
- 连接管理、心跳、重连复杂
- 基础设施运维门槛更高
Polling
适合：低频状态刷新、兜底通道
优点：
- 实现与兼容性最好
- 容易接入现有 API 网关
限制：
- 无法提供细粒度实时体验
- 频率过高会放大后端压力
三、决策树：如何做“够用且稳”的选型
可以用四个问题快速判断：
- 是否需要高频双向交互？
- 是：优先 WebSocket
- 否：看 2
- 是否主要是服务端推送进展？
- 是：优先 SSE
- 否：看 3
- 实时性要求是否低于 3-5 秒？
- 是：Polling 可接受
- 否：SSE/WebSocket
- 基础设施是否已具备 WS 观测与治理能力？
- 没有：先 SSE + Polling fallback
多数 AI 产品初期最稳方案是：SSE 主通道 + Polling 兜底。
四、重连与补拉：决定线上口碑的关键细节
不论用哪种机制，都建议统一这套协议策略：
- 每个事件带
sequence - 客户端记录
lastAckSequence - 重连时携带
since=lastAckSequence - 服务端返回缺失事件或任务快照
这样可以避免两类高频事故：
- 进度倒退
- 关键步骤“看不到但其实执行了”
五、UI 层一致性：别让展示逻辑反噬通信层
前端建议遵循：
- 事件入 store，再派生 UI
- UI 状态不可直接覆盖，只能由事件推进
- 任务终态（成功/失败/取消）不可被旧事件回滚
这能显著降低乱序事件导致的闪烁与误判。
与控制台设计可联动阅读：
六、生产建议：分阶段演进，而不是一次到位
阶段 1：SSE + Polling fallback
- 满足大多数单向长任务
- 成本低、排障快
阶段 2：补全重连与补拉协议
- 引入序号、快照、追平机制
阶段 3：局部引入 WebSocket
- 仅在高频双向场景（协作编辑、实时多人控制）启用
这样可以避免“为未来扩展过早复杂化”。