请解释在生成题目的场景中，采用 SSE 技术把结果实时推送给前端的原因，并说明除了 SSE 之外还有哪些可行的替代实现方案？

回答思路

1. 【回答框架 1】SSE 是 Server-Sent Events 的缩写，基于 HTTP 长连接，服务端单向推送文本数据到客户端。核心特征是使用 text/event-stream 媒体类型，通过 EventSource 接口接收，支持自动重连和事件 ID。相比 WebSocket，它是单向的，实现更简单，且原生支持 HTTP 协议，便于穿透代理和防火墙。
2. 【回答框架 2】在实时返回生成题目的场景中，采用 SSE 是因为生成过程是服务端主动、持续地输出结果到客户端，客户端无需频繁发送请求，减少轮询开销。SSE 能保持连接，服务端可以分多次推送生成进度或最终题目，同时客户端自动处理重连，提高可靠性。
3. 【回答框架 3】其他实现方案包括：WebSocket 全双工通信，适合需要双向交互的场景，但实现复杂度较高；长轮询（Long Polling）通过客户端不断发起请求，服务端挂起直到有新数据，兼容性好但服务器压力较大；短轮询定时请求，实时性较低且浪费资源。另外也可考虑 HTTP/2 Server Push，但主要用于静态资源，不适用于动态数据推送。
4. 【回答框架 4】选择方案时需要权衡实时性、连接管理复杂度、浏览器兼容性、服务器资源占用。SSE 适合服务端单向推送、且数据量适中、需要简单实现的场景。
5. 【回答框架 5】实现 SSE 时需要注意连接超时、重连策略、缓存控制，避免代理缓冲影响实时性。
6. 【关键点 1】SSE 基于 HTTP，服务端单向推送，适合题目生成这类服务端主动输出的场景。
7. 【关键点 2】相比 WebSocket，SSE 实现简单，浏览器原生支持 EventSource，自动重连。
8. 【关键点 3】替代方案有 WebSocket、长轮询、短轮询，各有优缺点。
9. 【关键点 4】选择方案需考虑实时性、双向通信需求、资源占用和兼容性。
10. 【易错点 1】不要认为 SSE 支持双向通信，它仅支持服务端到客户端单向推送。
11. 【易错点 2】SSE 不适合高频大量数据推送，因为基于文本流，且连接数过多会占用服务器资源。
12. 【易错点 3】长轮询和短轮询会频繁建立连接，需要避免高并发下的资源浪费。