定时轮询获取数据 vs SSE/WebSocket：通知功能技术选型疑问

一、定时轮询获取数据的核心弊端 #

• 资源严重浪费：不管服务器有没有新数据，前端都会按固定间隔发起HTTP请求，绝大多数请求都会返回空结果，白白消耗服务器的CPU、内存资源，以及客户端和服务器之间的带宽。比如设置10秒轮询一次，用户单日打开页面会产生近9000次请求，其中90%以上都是无效请求。
• 实时性无法保障：延迟完全取决于轮询间隔——如果新通知在轮询刚结束后产生，用户要等完整个间隔周期才能收到；缩短间隔会加剧资源浪费，拉长间隔又会让通知滞后，根本做不到“及时接收”。
• 连接开销过高：每次HTTP请求都要经历TCP三次握手、请求头（Cookie、User-Agent等冗余信息）传输、连接断开的流程，这些额外开销在用户量较大时，会给服务器带来巨大压力。
• 用户体验差：滞后的通知会让用户错过关键信息，比如即时消息、系统告警，体验远不如实时推送的方案。

二、是否可以仅采用定时轮询？ #

如果你的通知场景实时性要求极低（比如每日一次的系统公告），或者用户规模极小，定时轮询勉强可以用。但只要涉及“及时接收”的核心需求（比如消息通知、订单状态更新），定时轮询的弊端会被无限放大，完全不适合作为核心实现方案。

三、为何普遍选择SSE或WebSocket而非定时轮询？ #

• 实时性拉满：SSE是服务器主动推送模式，有新数据立刻发送给前端；WebSocket是双向全双工长连接，服务器能随时推送数据，延迟几乎为0，完美匹配“及时接收”的需求。
• 资源效率极高：两者都是一次握手后保持持久连接，没有空请求的浪费——SSE基于HTTP长连接，仅服务器单向推送；WebSocket则支持双向通信，服务器和客户端都能随时发送数据，大幅降低服务器和带宽的负载。
• 实现更简洁：SSE前端直接用EventSource API，几行代码就能完成接收、重连逻辑；WebSocket也有成熟的浏览器API，无需自己编写复杂的定时、请求失败重试逻辑。
• 场景适配性更强：WebSocket适合需要双向交互的场景（比如在线聊天）；SSE专门针对服务器单向推送做了优化（自动重连、事件类型区分），更贴合通知类场景的需求。

内容的提问来源于stack exchange，提问作者user6377312