第一次在生产环境部署 SSE，我以为自己捡到宝——不需要 WebSocket 那种心跳维持，浏览器原生支持，三行代码就能推送消息。结果凌晨三点被报警叫醒，几百个客户端疯狂重连把 Node 服务打挂了。那是去年冬天的事了。现在回头看，这玩意儿远不是文档上写的那么简单。
事件骨骼：text/event-stream 的微观解析
SSE 的协议层极薄，但薄得像手术刀——稍微偏一点就会出血。数据格式规定每条消息由若干 field:value 行构成，以双换行结尾。常用字段就四个：data（荷载）、event（事件类型）、id（消息 ID）、retry（重连间隔）。简单吧？但你试着自己写一个解析器就知道坑在哪里。
浏览器里的 EventSource 对象藏了一个状态机。它不只是一行行读，而是按照 stream 的模式分块接收。问题出在分块边界——假设你服务端一次 flush 了半个 data 行，浏览器得缓存起来等换行符。那些没带换行符的 chunk 会堆积在内存里，可能导致 onmessage 迟迟不触发。我见过一个案例，服务端忘了在每条消息后加换行，客户端居然一直沉默，直到连接超时。
通俗地类比，SSE 就像一条单向传送带，包裹连续丢过来，但分拣机器只能识别完整包裹——如果包裹破了，机器就傻等下一个完整包裹。你必须在服务端强制每条消息以双换行结尾，哪怕只发一个注释心跳，也得带换行。
连接的生命线：从压测数据看 SSE 的真正优势
很多人拿 SSE 跟 WebSocket 比功能丰富度，这完全搞错了坐标系。SSE 的场景是 单向、低延迟、可缓存 的流——比如股票行情、日志推送。我用两台 4 核 8G 的虚拟机，Node 服务单进程，压测工具模拟 5000 并发连接，每条消息 1KB，每秒推送 50 条。短轮询在相同消息频率下，服务器 CPU 直接飙到 90%，因为每个请求都要经过完整的 HTTP 握手和路由；而 SSE 长连接模式下，CPU 稳定在 20% 左右，内存占用多了但可控（每个连接大约 30KB）。
最关键的数字其实是 延迟方差。短轮询的 P99 延迟可能冲到 2 秒以上，取决于轮询间隔；SSE 的推送延迟几乎等于网络 RTT，P99 压测在 50ms 以内。对于金融盯盘系统，这点差距就是命。
不过话说回来，别在 HTTP/1.1 下用 SSE 做高并发，因为浏览器对每个域名的连接数限制（Chrome 约 6 个）会让你傻眼——开着 6 个 Tab 就把连接数占满，其他请求全堵在队头。这是血淋淋的教训。上 HTTP/2 吧，否则你会后悔。
生产环境的三道鬼门关
第一关：自动重连的雪崩效应。 EventSource 默认会 re-connect，而且不带退避算法。如果你的服务端因为过载断开了连接，瞬间上千客户端同时发起重连，形成流量尖刺——直接二次击垮服务。解决方案：在服务端通过 retry 字段强制客户端采用指数退避，例如设置 retry: 5000 加上换行表示 5 秒基础间隔，并在服务端实现分段随机延迟验证。
第二关：Last-Event-ID 的潜规则。 重连时浏览器会带上 Last-Event-ID 头，这本来是个补充机制——但如果你在消息里用了 id 字段，重连后可能收到重复数据，或者更惨，跳过了一段数据。为什么？因为服务端通常根据 Last-Event-ID 来续传，但如果你的 ID 是自增序列，而服务端只在崩溃时丢失了内存状态，那么重启后 ID 回退，客户端拿着一个较高的 ID 请求，服务端返回从当前 ID 开始——中间的消息就丢了。正确姿势：ID 必须是可持久化、单调递增且按主题分区的。
第三关：代理和防火墙的隐形刽子手。 很多反向代理（比如 Nginx）默认会缓存响应或等待响应结束才转发，但 SSE 是长流，需要关闭缓冲：proxy_buffering off、chunked_transfer_encoding on，还得加一条 “X-Accel-Buffering: no” 响应头。忘了任何一个，你的数据就会在服务器里憋到 buffer 满才一股脑吐出去——客户端还以为断开了。
折腾完这些，晚上能睡好点了吗？也许吧，至少不会再被报警叫醒了。
