前端实时通知方案选型：短轮询、SSE、WebSocket 怎么选

前端要做“实时通知”时，很多团队第一反应是上 WebSocket。但并不是所有通知都需要双向长连接。后台未读数、订单状态、审批提醒、聊天消息、协作文档光标，它们看起来都和实时有关，实际对延迟、可靠性、服务器成本、浏览器兼容的要求完全不同。

本文不把短轮询、SSE、WebSocket 当成谁替代谁，而是按使用场景做一次选型：低频状态更新用什么，服务端主动通知用什么，双向互动用什么，以及什么时候应该先做降级和补偿接口。

使用场景：先问页面到底要多实时

选型前先把业务问题拆清楚。很多“实时”需求其实只要求用户在几十秒内看到变化，比如后台未读数、待办数量、普通审核提醒。这类需求对延迟不敏感，短轮询就能覆盖。

另一类是服务端有新消息就希望马上推到页面，例如订单支付成功、部署状态变更、系统告警。这类场景前端只接收服务端事件，SSE 往往更简单。

还有一类需要浏览器和服务端双向频繁通信，例如在线客服、协作编辑、多人游戏、实时控制台。此时 WebSocket 才是主角，因为它不只是“收通知”，还要持续发送用户动作。

候选方案：短轮询、SSE、WebSocket 各解决什么

短轮询的模型最直接：每隔一段时间请求一次接口，拿到最新状态后更新页面。优点是后端改动小、代理链路友好、排查简单；缺点是有固定延迟，空请求也会消耗资源。

let notifyTimer = 0;

async function pollUnreadCount() {
  const response = await fetch("/api/notifications/unread-count", {
    cache: "no-store"
  });
  const data = await response.json();
  renderUnreadBadge(data.count);

  notifyTimer = window.setTimeout(pollUnreadCount, 10000);
}

pollUnreadCount();

SSE 的模型是浏览器用 EventSource 建立一条接收通道，服务端持续把事件推给前端。它适合单向通知，浏览器断开后通常会自动重连，代码量比 WebSocket 少。

const source = new EventSource("/api/notifications/stream");

source.addEventListener("message", (event) => {
  const notice = JSON.parse(event.data);
  appendNotice(notice);
});

source.addEventListener("error", () => {
  showStatus("reconnecting");
});

WebSocket 的模型是建立双向连接，前端和服务端都可以主动发消息。它适合互动型业务，但也带来连接状态、心跳、重连、订阅恢复、权限刷新等维护成本。

const ws = new WebSocket("wss://example.com/ws");

ws.addEventListener("open", () => {
  ws.send(JSON.stringify({
    type: "subscribe",
    topic: "orders"
  }));
});

ws.addEventListener("message", (event) => {
  handleMessage(JSON.parse(event.data));
});

下面这张图把三种方案放到同一条生命周期时间线里。选型时重点看状态变化是否符合业务，而不是只看方案名是否“高级”。

对比维度：方向、延迟、成本和恢复能力

真正影响选型的不是接口写法，而是这几个维度。

如果业务只要求“用户过一会儿能看到变化”，短轮询的可维护性最好。如果服务端消息需要尽快到达，但前端不需要频繁反向发送业务消息，SSE 更轻。如果双方都要高频交互，再考虑 WebSocket。

推荐选择：按通知类型做决策

推荐流程是先按业务类型分流，再看网络和运维约束。不要一上来就问“哪个技术更实时”，先问“这条消息迟到多少秒可以接受”。

低频状态：优先短轮询

后台首页的未读数、待办数、任务列表状态，通常不需要毫秒级更新。可以把轮询间隔设为 10 到 30 秒，并在页面隐藏时暂停，页面重新可见时立即刷新一次。

document.addEventListener("visibilitychange", () => {
  if (document.hidden) {
    clearTimeout(notifyTimer);
    return;
  }
  pollUnreadCount();
});

服务端通知：优先 SSE

如果页面只需要接收服务端事件，例如任务进度、订单状态、系统公告，SSE 的复杂度低。后端按事件流输出，前端监听消息并更新 UI。需要注意代理缓冲、登录态过期和事件补偿。

重要通知不要只依赖连接本身。建议服务端提供一份状态查询接口，页面重连后主动拉取最近状态，避免断线期间漏掉关键变化。

双向协作：使用 WebSocket

聊天、协作编辑、实时控制台这类场景，前端不仅要接收消息，还要持续发送用户动作。WebSocket 的价值在这里才明显。对应地，也要准备连接状态机、心跳保活、退避重连、恢复订阅和消息去重。

如果只是一个后台通知铃铛，用 WebSocket 反而会引入过多维护点。连接数、网关、鉴权刷新、服务端广播、浏览器休眠恢复，都会变成后续排查成本。

不适用情况：别把简单通知做成复杂长连接

下面几类情况不建议直接上 WebSocket：

• 低频后台提醒：用户不要求立即看到，短轮询更省心。
• 只有服务端单向推送：没有前端高频发送动作，SSE 更轻。
• 后端没有连接治理能力：没有心跳、限流、灰度和监控时，长连接上线风险更高。
• 消息必须可靠到达：无论选哪种方案，都需要状态查询、消息 ID 或补偿接口。

同样，也不要把短轮询间隔设得过短。每 1 秒轮询一次，看起来接近实时，实际上会制造大量空请求。此时应该重新确认业务是否更适合 SSE 或 WebSocket。

决策表：落地时怎么选

总结一下：短轮询解决“定时看一眼”，SSE 解决“服务端有事就告诉我”，WebSocket 解决“双方持续互动”。选型时先按业务延迟和通信方向分类，再补上重连、状态查询和监控验证。这样做出来的实时通知更容易上线，也更容易在出问题时定位。