在前端开发中，如何通过 Server-Sent Events（SSE）实现与后端的流式通信，并在界面上呈现类似 AI 逐字输出的打字机效果？请说明关键实现步骤及注意事项。
考察说明
考查对 SSE 通信机制的理解，以及在前端处理流式数据并实现打字机效果的实践能力。
回答思路
- 【回答框架 1】SSE 是基于 HTTP 的单向服务器推送技术，使用 text/event-stream 媒体类型，通过 EventSource API 在前端建立长连接。与 WebSocket 不同，SSE 仅支持服务器到客户端的消息推送，但具有自动重连、基于 HTTP 的兼容性等优势。
- 【回答框架 2】前端实现时，创建 EventSource 实例指向后端的流式接口，监听 onmessage 或自定义事件。对于打字机效果，一般是每次收到数据块后，将文本追加到缓冲区，利用 setInterval 或 requestAnimationFrame 控制逐字渲染，避免频繁 DOM 操作导致的性能问题。
- 【回答框架 3】在实际项目中，需要考虑中断恢复：记录已处理的消息 ID（通过 Last-Event-ID），在重连时从上次位置继续接收。同时要处理连接状态变化（onopen、onerror），在错误时触发重连或提示用户。
- 【回答框架 4】打字机效果的优化：可以使用文本节点的拆分、CSS 动画或离屏渲染等技术，减少重排；对于大量文本，可每批渲染一定字数，而不是逐字插入 DOM，以降低性能开销。
- 【回答框架 5】前后端需约定数据格式，如 JSON 或纯文本，并处理异常情况，如后端返回错误码或连接超时。可考虑添加心跳机制保持连接活跃，并设置合理的重试策略。
- 【关键点 1】SSE 依赖 HTTP，EventSource 自动重连；与 WebSocket 相比，SSE 是单向的，但实现更简单。
- 【关键点 2】打字机效果的核心是控制消息的渲染节奏，常用定时器或 requestAnimationFrame 实现。
- 【关键点 3】需要处理重连和断线续传，通过 Last-Event-ID 确保消息不丢失。
- 【关键点 4】注意性能：避免每收到一个字符就操作 DOM，可采用批量渲染或虚拟滚动。
- 【关键点 5】前后端需约定数据格式，并实现错误处理和心跳机制。
- 【易错点 1】混淆 SSE 与 WebSocket 的能力，SSE 仅支持服务器到客户端，不能作为双向通信。
- 【易错点 2】不处理重连机制，导致连接断开后数据无法恢复。
- 【易错点 3】逐字操作 DOM 导致性能下降，应使用批量渲染或 requestAnimationFrame 优化。