前端实时数据：轮询、WebSocket、SSE 到底怎么选？聊聊弱网下的重连策略与成本

背景

社区里前端侧已经攒了不少干货：#180 聊过弱网下超时与重试的默认值与边界，#220 那篇《前端请求竞态治理》讲透了 AbortController + 请求序号的坑。但「实时数据」这个方向我观察到的现状是——每个团队都在凭直觉选方案：要么无脑 3s 轮询，要么一上来就 WebSocket，很少有人把「轮询 / WS / SSE」当成一个成本-收益权衡问题来算账。

我 5 年前端，做过 B 端监控看板也做过 C 端 IM，真实体感是：这三条路的落地成本完全不在一个量级，而大多数人只比较了「实时性」这一个维度。

几种常见做法（分歧所在）

1. 轮询派：setInterval 或递归 setTimeout 每 2~5s 拉一次。优点是零后端改造、跨网络环境最稳（NAT、代理、办公网白名单都天然支持）；缺点是空转浪费——监控看板 99% 的时间没有新数据，但请求照发，后端 QPS 是持续性的。我见过一个 50 并发在线的看板，纯轮询就把一个 P99 本来 80ms 的接口打到 400ms。
2. WebSocket 派：长连接 + 服务端推送。实时性最好，但成本是持续的：网关要支持 upgrade、NAT 保活要用心跳、断线重连的指数退避 + jitter 是必写代码、后端要为每条连接维持内存态。B 端办公网里，我遇到过 3 次「WS 连上了但消息不推」的诡异问题，最后都是中间代理把空闲连接掐了——排查一次 2 天起步。
3. SSE 派（HTTP 单向流）：折中方案，复用 HTTP 语义、天然走代理、断线浏览器自动重连（Last-Event-ID）。但浏览器并发上限 6 个 HTTP/1.1 连接（HTTP/2 下缓解）、部分老网关不认 text/event-stream 的 chunked 编码，我们在一个客户内网环境直接翻车过。

我的倾向

我倾向默认轮询 + 一个硬约束：

• B 端、数据变更频率 < 1 次/分钟：轮询，间隔取「数据最小可感知粒度」，比如订单状态就 10s，别追求 1s；
• B 端、需要秒级 + 双向：WS，但必须有「WS 失败自动降级到轮询」的兜底，这条兜底代码 30 行以内，但能挡住 80% 的「连不上」投诉；
• C 端、单向推送、流量大：SSE，前提是网关层确认支持 chunked + 不缓冲，先在 staging 用 curl -N 验证再上。

关键判据不是「实时性」，而是**「后端为这条通道付出的持续成本」**——连接内存、心跳 QPS、代理兼容性排查时间。没有 on-call 的团队上 WS，等于给自己挖一个永远填不满的坑（和 #431 聊稳定性水位是同一个道理）。

想听大家聊的

1. 你们团队的「实时数据」默认走哪条路？当初是谁拍板的，判据是什么？
2. 有没有反例——某个看起来「过度」的 WS 投入，事后证明救了你一命？（我想收集真实案例，校准我的「默认轮询」判断）
3. 弱网 / 办公网代理环境下，WS 的心跳间隔你们怎么定的？有没有踩过「心跳太密被代理当攻击」或「心跳太疏被 NAT 掐」的坑？
4. SSE 的浏览器并发上限，你们实际项目里有没有真的被卡过？HTTP/2 上线后这个约束还成立吗？

欢迎带真实场景来聊，别只聊原则。