SSE不适合高频股票行情场景，因其基于HTTP长连接、文本格式开销大、浏览器缓冲延迟高、无内置心跳与序列号校验，且不支持二进制传输，难以满足毫秒级更新、零丢失和精确重传的刚性需求。
SSE（Server-Sent Events）适合轻量、单向（服务端→客户端）的实时数据推送，但不适合高频股票行情场景。原因很直接：SSE 基于 HTTP 长连接，每次事件需带文本格式（如 data: {...}\n\n），协议开销大；浏览器对单个域名的并发连接数有限制（通常 6 个）；且无法复用连接做双向通信或精确控制重传、心跳、断线补偿等——这些恰恰是行情系统的核心需求。
为什么 SSE 不适合高频股票行情
股票行情更新频率常达毫秒级（如 Level 2 行情每秒数百次），而 SSE 的典型瓶颈包括：
- HTTP 头部重复发送（每次 event 都含
Content-Type、Cache-Control等），带宽浪费明显； - 浏览器强制缓冲（尤其 Safari 和旧版 Chrome），可能延迟 1–3 秒才触发
onmessage； - 无内置心跳机制，网络闪断时恢复慢，容易丢失中间行情；
- 不支持二进制传输，JSON 字符串解析开销在高吞吐下不可忽视。
更合适的替代方案：WebSocket + 心跳与增量同步
生产环境普遍采用 WebSocket，配合以下关键设计：
- 二进制协议封装：用 Protocol Buffers 或自定义二进制帧（如 4 字节长度头 + 行情结构体），体积比 JSON 小 60%+；
-
订阅/退订控制：客户端发
{"type":"subscribe","symbols":["AAPL","TSLA"]}，服务端只推相关行情，避免广播风暴； - 心跳保活与序列号校验：客户端每 15 秒发 ping，服务端回 pong；每条行情带递增 seq ID，客户端检测跳号即触发快照拉取；
- 连接降级兜底：WebSocket 断开后自动尝试 reconnect，失败则 fallback 到短轮询（如 /tick?last_seq=12345）补漏。
如果硬要用 SSE：必须做的最小化优化
仅限低频行情（如每秒 ≤ 5 条）或 PoC 场景，需强制规避默认行为：
立即学习“Java免费学习笔记（深入）”；
-
禁用缓冲：服务端响应头加
Cache-Control: no-cache、X-Accel-Buffering: no（Nginx）、response.flush()（Node.js）； -
合并推送：将同一毫秒内的多只股票打包为一个 event（
data: [{"sym":"AAPL","p":182.3,"v":1200},{"sym":"MSFT","p":375.1,"v":890}]\n\n），减少 HTTP 开销； -
客户端防抖解析：用
TextDecoder解析 UTF-8 流，避免event.data字符串拼接错误； -
超时重连策略：监听
onerror后延迟 1s、2s、4s 指数退避重连，避免雪崩。
真实行情系统的关键补充
无论选哪种传输层，业务层必须配套：
-
快照+增量模型：首次连接返回全量快照（含 bid/ask/last/volume），后续只推变化字段（如
{"sym":"GOOGL","last":142.8,"change":0.15}）； - 服务端聚合：行情源（如交易所 API）接入后，在服务端做 tick 合并（防重复）、价格过滤（剔除异常值）、时间戳对齐（统一纳秒精度）；
- 客户端渲染节流：即使收到每秒 100 条更新，DOM 只按 requestAnimationFrame 频率（≈60fps）刷新，避免 layout thrashing。
不复杂但容易忽略：高频行情的本质不是“推得快”，而是“推得准、不丢、可追溯”。SSE 在这个维度上先天不足，选型时优先考虑 WebSocket 或专业消息中间件（如 Kafka + WebRTC DataChannel 用于超低延迟）。
