WebSocket还是SSE：AI流式输出通常不需要双向连接

AI回答逐步显示，而用户只在提问、取消或反馈时发送请求，通常可以优先选择SSE配合普通HTTP：持续发生的是服务端向浏览器交付文本，偶发的上行操作可以走独立请求。HTML标准中的EventSource定义描述了这种由服务器发送UTF-8文本事件的连接，也规定了浏览器在适用情况下重新连接的行为。

如果客户端也要在同一连接上不断发送消息，或要直接传输二进制内容，WebSocket更合适。MDN的WebSocket API说明列出了连接上的发送、接收和二进制数据能力，同时提醒开发者：浏览器的WebSocket接口没有自动背压机制，消息到达速度超过处理速度时，缓冲可能持续增长。因此，选型除了看通信方向，也要看消息形态和消费能力。

四类流量怎样划分

AI文本生成通常把令牌或文本片段接连送给浏览器，“逐字输出”只是界面效果，并不意味着每次事件恰好包含一个汉字。用户先提交问题，服务端随后交付增量回答；停止生成可以另发请求。如果产品还要求持续上传音频、在回答中实时插话，并让上下行消息交错处理，单条双向连接的价值就明显增加。

通知也主要由服务器发起。订单状态、任务进度或构建日志更新可以作为下行事件交付，用户点击确认仍用普通请求。Vercel的实时通信选型指南也将AI文本流和通知归入以服务端推送为主的流量，将持续双向交互归入更适合WebSocket的场景。这里的判断依据是消息往返的频率，而不是界面是否看起来“实时”。

协同编辑则常有持续上行：参与者提交编辑操作，同时接收他人的操作、光标位置或在线状态。WebSocket允许双方在同一连接上持续收发，但它只提供传输通道；操作顺序、冲突处理以及断线后的文档状态仍需应用管理。普通问答式聊天可以像AI文本生成一样，发送消息后接收流式回复；若聊天同时包含频繁的输入状态、协作操作或音视频片段，就应按实际流量重新评估。

把选择条件放在一起看

通信方向是起点，消息类型、断线要求和部署链路会改变最终选择。以下判断适用于浏览器应用的常见实现，条件相互关联，不能只凭其中一项决定架构。

• 上下行方向：服务器持续发送、客户端偶尔提交请求，优先考虑SSE加HTTP；两侧都要持续发消息，优先评估WebSocket。
• 消息类型：增量文本及可序列化为文本的事件适合SSE；音频片段等需要直接收发的二进制消息更适合WebSocket。将二进制数据编码进文本流会增加编码和解码工作。
• 重连与内容恢复：浏览器EventSource通常会尝试重连，但业务消息能否补发取决于服务端；WebSocket通常连重连时机和状态同步都要由应用安排。
• 代理与网关：SSE要检查HTTP响应是否被缓冲、空闲连接何时被切断；WebSocket还要确认连接建立过程及后续长连接受到网关支持。
• 扩容：两种方案都占用持续连接。消息要送到不同实例上的订阅者时，都需要考虑实例间分发；若会话进度只保存在单个实例，重连到其他实例会带来状态恢复问题。
• 浏览器限制：多个标签页同时订阅时，要核对浏览器实际使用的HTTP版本及可用连接或并发流容量。

重连之后，内容从哪里继续

连接重新建立与内容正确恢复是两件事。EventSource可在重连时把最近的事件标识交给服务器；要让这个标识发挥作用，服务端还得保留可重放的事件，并明确从哪个位置补发。通知若不能遗漏，可以为事件编号并保存一段历史，客户端则要处理可能重复送达的内容。若通知只表示“状态已变化”，重连后重新获取完整状态，再接收后续增量，也是一种选择。

还要区分SSE事件格式与EventSource这个浏览器接口。EventSource按URL建立接收事件的连接，具有浏览器提供的重连行为；如果应用把提问放进POST，并通过fetch读取该请求的流式响应，即使响应采用SSE格式，也不能把EventSource的自动重连直接算作这个fetch请求的能力。应用需要决定请求中断后是否重试、是否会重复触发生成，以及如何取回已产生的回答。

AI生成任务尤其需要明确这个边界。连接断开后能否接着输出，取决于服务端是否仍在运行任务、是否保存了任务标识与已经生成的片段。浏览器重新接上连接不会凭空恢复已经丢弃的内容；若任务无法续传，界面应把中断状态与新的回答区分开，避免把两次生成拼成一条看似连续的结果。WebSocket应用面对同样的业务问题，只是还要自行处理连接重建。

代理、浏览器和扩容的实际代价

SSE使用持续的HTTP响应，沿用现有HTTP链路，但代理若缓冲响应，服务器已经发送的事件可能延迟到达浏览器；空闲超时也可能切断长时间没有数据的连接。MDN的SSE使用说明给出了关闭响应缓冲的示例，并指出未通过HTTP/2使用时，同一浏览器与域名的SSE连接上限为6条；使用HTTP/2时，并发流上限由客户端与服务器协商。多标签页产品因此要看实际协商的链路，而不是只看源站配置。

WebSocket需要网关正确处理建立连接的过程，并为长连接设置合适的超时策略；企业代理等中间设备也可能影响连接。两种方式都要考虑服务端的连接对象、待发送缓冲和订阅状态。SSE使用较简单的响应流模型，但这不足以推出任何实现都比WebSocket省内存：慢客户端、消息积压和应用保存的会话数据，都会改变实际资源占用。

跨实例推送时，协议本身不会替应用广播业务事件。假如通知由一个实例产生，而订阅者分散在其他实例，消息仍需经过共享存储或发布订阅系统。协同编辑若把房间成员和文档进度仅留在进程内，实例重启或客户端重连就可能暴露状态缺口。扩容方案应同时覆盖连接如何分配、事件如何分发，以及业务状态存放在哪里。

性能要按消息规模和操作来比较

WebSocket建立连接后可以反复发送消息，但这不等于它在所有负载下都更快。一项公开的协议实验使用Python服务和MongoDB比较不同实现：读取单条记录时，WebSocket实现的平均用时与REST实现接近；一次读取100条记录时，WebSocket实现在该实验环境中平均用时最长。这个结果属于特定程序、数据库操作与测试环境，实验没有比较SSE，也不能直接用来排列AI文本流的速度。

对于AI回答，更有意义的负载指标是片段大小、发送间隔、首段到达时间、完整回答耗时，以及慢客户端造成的缓冲增长。短片段频繁发送与一次交付较大结果，会让协议开销和应用处理成本占据不同权重。若业务流量仍是提问后持续接收文本，SSE加HTTP是合理的起点；持续上行、原生二进制消息，或针对自身负载的测量结果，才构成改用WebSocket的具体理由。

相关阅读：

• Docker还是Kubernetes：容器能跑起来，不代表需要集群
• Qdrant还是Milvus？内存吃紧时胜负会反转
• Ghost还是WordPress.com：订阅规模一变，成本就会反转