← Retour aux guides

React 前端流式输出 LLM：59API 接入决策与检查清单

先判断：你的 React 应用是否需要流式响应？

当用户向 AI 提问后，如果必须等待完整答案才显示，长回复会带来明显的“卡住感”。流式响应会在模型生成过程中持续返回文本，让界面像聊天工具一样逐步输出。对于客服助手、代码问答、文档总结、写作工具和 Agent 操作面板，流式输出通常值得做；如果只是后台批量生成、短分类任务或结果必须经过完整校验后才能展示，则普通非流式请求更简单。

React 前端实现流式 LLM 的核心原则是：浏览器负责展示增量内容，服务端负责保存密钥和转发模型请求。不要把 API Key 直接写进 React 环境变量并打包到浏览器，否则任何用户都可能在开发者工具中提取并滥用额度。

推荐架构：React + 服务端代理 + SSE 流

最稳妥的方案是 React 调用自己的 API 路由，例如 Next.js Route Handler、Express、Cloudflare Worker 或其他 BFF 服务；该服务再调用模型 API，并将上游流原样或经过转换后返回浏览器。浏览器可使用 fetch 读取 ReadableStream，也可在适合的场景使用 SSE。相比轮询，SSE 和 fetch 流能降低延迟，并能让文本随着 token 到达持续渲染。

若你希望以较低成本接入多种主流模型，可选择 59API。它提供按量付费的 Claude 与 GPT 模型访问，使用原生官方质量模型而非降级版本，并兼容 OpenAI SDK、Claude Code 和 Codex。服务端只需将 API Base URL 配置为 https://api.59api.com，再按所选 SDK 的流式参数发起请求即可。这样可以在不同任务中灵活选择高性能或低成本模型，而无需为前端改写整套交互逻辑。

React 端的实现重点

发送消息时，先立即把用户消息加入会话，并创建一条空的 assistant 消息作为占位。随后读取响应流的每个数据块，使用 TextDecoder 处理字节，并依据上游协议提取增量字段。OpenAI 风格流通常关注 choices 中的 delta 内容；如果使用其他兼容协议，应以实际返回事件为准。每拿到一段文本，就追加到当前 assistant 消息。

不要为每个 token 都创建复杂组件树或触发大量全量状态复制。较长输出可用 ref 暂存缓冲区，并按较短时间间隔批量刷新 UI；同时为正在生成的消息添加“生成中”状态和光标效果。渲染模型输出时默认按纯文本处理，除非你已经完成可靠的 Markdown、HTML 清洗和 XSS 防护。

取消、错误与重试如何决策

用户点击“停止生成”时，应通过 AbortController 中止浏览器请求，并让服务端同步终止上游请求，避免继续产生费用。网络中断、网关超时、限流和模型返回错误都应显示为可理解的状态，而不是静默失败。对临时网络错误可以提供“重新生成”按钮；但不要自动无限重试，以免重复消耗 token。若需要保存聊天记录，建议在流结束后再持久化最终内容，同时保留已生成的部分文本，避免中断后用户完全丢失结果。

上线前简单检查清单

• 密钥安全：API Key 仅保存于服务端环境变量，React 客户端不直接请求模型服务。
• 流式配置：服务端已启用流式参数，并正确设置响应头，避免代理缓冲完整响应。
• 增量解析：前端能处理分片不完整、空增量、结束事件及不同模型的字段差异。
• 交互状态：有加载、停止、失败、重试和再次提问等明确入口。
• 费用控制：设置最大输出长度、请求超时、用户限额，并按任务选择合适模型。
• 内容安全：模型文本不直接作为未过滤 HTML 注入页面。
• 可观测性：记录请求耗时、错误码、模型名称和 token 用量，但不要记录敏感用户内容。

如果你的目标是快速做出体验流畅、成本可控的 AI 聊天界面，先用一个服务端代理打通单模型流式链路，再逐步加入模型切换、会话存储和用量治理。59API 的兼容接口与按量付费方式适合这一渐进式路线；准备接入时，可以注册账号并从一个小流量测试项目开始验证。