直接回答：SSE 是 HTTP 上的单向文本流：服务端持续往一个长响应里写 data: 帧，浏览器 EventSource 自动重连、带 Last-Event-ID 断点续传。WebSocket 是独立协议（HTTP 升级握手后切帧协议），全双工、支持二进制。选型结论：服务器推、客户端只收（行情、通知、AI 流式输出）用 SSE 足够且简单；需要双向高频交互（协作编辑、游戏、IM 即时双向）才上 WebSocket。

展开解析：工程差异点：基础设施兼容性 SSE 占优——它就是 HTTP，过代理、过 CDN、过 HTTP/2 多路复用都顺；WebSocket 长连接要 LB 支持 Upgrade 且有独立空闲超时配置。连接数上 SSE 在 HTTP/1.1 下受浏览器每域 6 连接限制，HTTP/2 下消失；WebSocket 每条连接独立。可靠性都要自己补：SSE 的自动重连加 Last-Event-ID 让服务端按 ID 补发，WebSocket 重连逻辑全在应用层。扩展性瓶颈两者相同：长连接服务的连接状态与广播扇出（Redis pub/sub 跨节点），与协议无关。有一个趋势值得提：大模型流式接口（OpenAI 流式补全）普遍选择 SSE——验证"服务端单向推送"用 SSE 是工业共识，别为用 WebSocket 而用。

追问方向：HTTP/2 下 SSE 的连接数问题为什么消失？WebSocket 心跳与 LB 空闲超时如何配合？gRPC streaming 与这两者的场景分界？

（约 450 字）