1. 为什么需要SSE？实时通信的轻量之选
上周排查线上问题时，发现有个项目为了实时更新订单状态，竟然用setInterval每隔5秒轮询接口。看着监控里密密麻麻的请求曲线，我当即决定用SSE重构这套机制。SSE（Server-Sent Events）作为HTML5标准的一部分，完美解决了这类单向实时数据推送的需求。
与WebSocket相比，SSE具有三大天然优势：
- 基于HTTP协议，无需额外握手协议
- 自动重连机制内置
- 浏览器原生支持EventSource API
最近在面试前端候选人时，发现80%的人对SSE的认知还停留在"听说过"的阶段。实际上在消息通知、实时日志、股票行情等场景下，SSE才是更合适的选择。去年某电商大促时，我们通过SSE将服务器压力降低了73%（从QPS 12万降至3.2万）。
2. 核心机制解析：SSE如何工作
2.1 协议层关键细节
SSE的魔法始于这两个HTTP头：
Content-Type: text/event-stream Cache-Control: no-cache Connection: keep-alive服务端通过维护一个持久连接，以特定格式发送事件流。每条消息由字段和值组成，例如：
event: orderUpdate data: {"id":123,"status":"shipped"} retry: 5000关键点：每个消息必须以两个\n结尾。我曾踩过坑，少一个换行符会导致浏览器端无法正常解析。
2.2 浏览器端EventSource实战
前端使用简单到令人发指：
const es = new EventSource('/order-updates'); // 通用事件处理器 es.onmessage = e => { console.log(JSON.parse(e.data)); }; // 特定事件处理器 es.addEventListener('orderUpdate', e => { updateOrderStatus(JSON.parse(e.data)); });实测中发现几个重要特性：
- 自动重连：连接中断后默认3秒重试（可通过retry字段配置）
- 消息ID追踪：Last-Event-ID头实现断点续传
- 跨域支持：与fetch API同源的CORS策略
3. 服务端实现方案对比
3.1 Node.js示例（Express）
app.get('/stream', (req, res) => { res.writeHead(200, { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache', 'Connection': 'keep-alive' }); const timer = setInterval(() => { res.write(`data: ${JSON.stringify({time: Date.now()})}\n\n`); }, 1000); req.on('close', () => clearInterval(timer)); });3.2 Spring Boot实现
@GetMapping(path = "/updates", produces = "text/event-stream") public Flux<String> streamUpdates() { return Flux.interval(Duration.ofSeconds(1)) .map(seq -> "data: Update " + seq + "\n\n"); }3.3 生产环境注意事项
- 连接数限制：Nginx默认只允许1024个并发连接，需要调整
proxy_http_version 1.1; proxy_set_header Connection ""; proxy_buffering off; - 心跳机制：每15-20秒发送注释行保持连接
res.write(': heartbeat\n\n'); - 内存泄漏防范：务必监听close事件清理资源
4. 性能优化实战记录
去年优化监控系统时，我们遇到SSE连接数暴涨的问题。通过以下方案将单机承载能力从3k提升到15k+：
- 连接复用：改用HTTP/2减少TCP握手开销
- 智能压缩：对重复字段使用差分编码
- 批处理：将高频更新合并为批量消息
data: {"updates":[...]}\n\n - 客户端节流：通过
eventSource.reconnectInterval调整
实测数据显示，优化后CPU负载下降41%，内存消耗减少68%。特别提醒：避免在消息中包含冗余的字段名，每个字符在长连接中都会被持续传输。
5. 常见问题排坑指南
Q1：为什么Chrome显示pending状态？A：确保服务端不启用压缩，某些中间件会自动gzip事件流。
Q2：如何实现用户专属通道？
// 携带认证信息 const es = new EventSource('/stream?token=' + authToken);Q3：移动端频繁断开怎么办？
- 调整retry时间（建议5-10秒）
- 添加离线队列（localStorage暂存）
- 监听Page Visibility API
Q4：SSE vs WebSocket怎么选？
| 特性 | SSE | WebSocket |
|---|---|---|
| 协议 | HTTP | WS |
| 双向通信 | ❌ | ✅ |
| 断线恢复 | ✅ | ❌ |
| 二进制数据 | ❌ | ✅ |
曾有个物联网项目，我们同时使用两种方案：SSE推送状态更新，WebSocket处理控制指令。这种混合架构稳定运行了2年多。
6. 高级应用：SSE的创造性用法
场景1：配合Service Worker实现离线消息
self.addEventListener('message', event => { if (event.data.type === 'SSE_MESSAGE') { clients.matchAll().then(clients => { clients.forEach(client => client.postMessage(event.data)); }); } });场景2：大文件上传进度实时回显
// 服务端 res.write(`data: ${JSON.stringify({progress: 45})}\n\n`); // 前端 eventSource.onmessage = e => { progressBar.style.width = `${e.data.progress}%`; };最近在开发低代码平台时，我们用SSE实现了多人协作编辑的冲突提示功能。当检测到多人同时修改同一字段时，服务端会推送：
event: conflictWarning data: {"field": "title", "users": ["Alice", "Bob"]}这种实时轻量级的交互，如果用WebSocket实现至少要增加300%的代码量。SSE就像通信领域的瑞士军刀——简单但足够应对大多数场景。
