文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载导读本文聚焦 chatgpt-web 第8节流式接口对接讲解在前后端分离架构下React 前端如何通过跨域请求对接后端已就绪的流式异步应答接口并利用浏览器原生的fetchReadableStream逐块读取数据、逐步填充对话框最终呈现出 ChatGPT 式的打字机渐显效果。读完本文你将掌握 CORS 跨域对接、fetch调用接口的参数传递、ReadableStream流式数据的读取与解码以及把流式内容实时渲染进 React 消息记录里的完整方案并能结合 chatgpt-api 第4节 的后端实现与 Nginx 转发配置打通一条端到端可运行的流式对话链路。一、本章诉求让 ChatGPT 的对话动起来在《ChatGPT 微服务应用体系构建》这套课程里chatgpt-api工程模块已经完成了流式异步响应接口的开发与测试对应 第4节工程重构和流式异步响应接口实现服务端能够以 SSE 风格逐块推送 OpenAI 的应答数据。而前端chatgpt-web此前的工作对话框列表、对话框消息、完善对话处理都还停留在本地数据操作阶段。因此本章的诉求非常明确跨域对接后端接口将用户发送时的请求信息对话内容、上下文、模型选择等传递给后端流式接口接收后端应答结果把流式返回的数据块依次填充到消息记录中让文字像打字机一样逐字渐显。在 chatgpt-web 第8节 中明确点名了本章要用到的三个核心技术fetch 调用接口、ReadableStream 处理流式数据以及跨域处理。这三者分别对应了怎么把请求发出去怎么读回流式数据前后端分离下怎么让请求能发出去三个关键问题。二、目标效果对话内容的逐字渐显本章完成后的核心体验是用户发送提问后右侧对话框中的回答不是一次性整段出现的而是随着后端数据块的到达逐字逐段地打出来直到完整内容填充完毕。这种效果在 第6节完善对话处理 所实现的消息渲染基础上叠加而来——回答内容本身就是 Markdown 格式流式填充后再交由 Markdown 渲染组件展示。要实现这一效果前端需要完成两件事请求阶段构造带认证与对话上下文的请求体调用后端流式接口接收阶段通过ReadableStream持续读取响应体的数据块每收到一块就更新一次 React 状态驱动对话框内容刷新。三、跨域处理前后端分离的第一道关卡浏览器出于安全考虑默认不允许一个源Origin下的脚本去请求另一个源的资源这就是 CORSCross-Origin Resource Sharing跨域限制其本质是为了防止恶意网站读取或修改其他网站的数据典型的跨站脚本 XSS 攻击场景。在前后端分离的架构中chatgpt-web如https://gaga.plus与chatgpt-api服务往往部署在不同的域名或端口下因此跨域处理是接口对接的第一步。在 chatgpt 面试复盘 notes.md 的问答中给出了该项目的跨域落地方案开发阶段后端接口配置Access-Control-Allow-Origin: *放开所有来源方便本地调试上线阶段收紧为Access-Control-Allow-Origin: https://gaga.plus这类明确的业务域名只允许自己的前端页面跨域访问。Spring Boot 后端实现上可直接使用CrossOrigin注解配置允许的来源、方法与请求头同时该笔记也强调跨域只是第一步真正生产环境还涉及 Nginx 的 SSL 转发、鉴权校验等可参考 dev-ops 第4节Nginx环境配置。提醒跨域配置放开范围越大越方便但安全隐患也越大。开发环境用*图省事没问题线上务必收敛到自己的真实域名。四、fetch 调用接口把对话请求发给后端跨域打通后前端就可以用浏览器原生的fetch发起请求。与XMLHttpRequest相比fetch的 API 更现代、基于 Promise、写法更简洁且天然支持流式响应体的读取这正是本章选择它的原因。一个典型的流式对话请求示例如下思路示意可结合你的工程结构落地const res await fetch(/api/v1/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${token} // 携带登录鉴权信息 }, body: JSON.stringify({ model: gpt-3.5-turbo, // 模型选择对应后端多渠道策略 messages: conversation, // 对话上下文历史消息数组 stream: true // 开启流式应答 }) });需要传递的请求信息通常包括请求字段说明来源messages对话上下文历史消息 当前提问按 role 区分 system/user/assistant前端 chat-store 存储的对话记录model模型选择ChatGPT、ChatGLM 等输入框上方的控制栏参数token登录鉴权凭证放在请求头浏览器本地存储stream是否开启流式返回本章固定开启这些参数与 第6节完善对话处理 中输入框上方控制栏的设计一脉相承——用户在界面上选择的上下文、模型等配置最终都会被打包进这个请求体传给后端。后端收到后再经由 chatgpt-sdk 第2节流式应答会话设计实现 的会话工厂与事件监听机制把 OpenAI 的应答逐块推回。五、ReadableStream 流式读取让数据逐块流进对话框这是本章的核心难点。普通接口返回的是一个完整 JSON而流式接口返回的响应体是一个持续推送数据的流。fetch的响应对象res.body就是一个ReadableStream配合getReader()可以逐块读取其中的数据。典型读取流程如下思路示意const reader res.body.getReader(); const decoder new TextDecoder(utf-8); // 把 Uint8Array 字节解码为字符串 let assistantMessage ; while (true) { const { done, value } await reader.read(); if (done) break; // 流结束 const chunk decoder.decode(value, { stream: true }); // 解析 SSE 格式的 data: 前缀提取真实文本片段 const text parseSSE(chunk); assistantMessage text; // 累积完整回答 setMessages(prev updateLastMessage(prev, assistantMessage)); // 渐显更新 }这个循环里有两个关键点decoder.decode(value, { stream: true })流式数据是分块到达的一个中文字符可能被拆到两个数据块里stream: true告诉解码器还有后续数据避免出现乱码每次读取后立即更新 React 状态每收到一个数据块就触发一次状态更新让assistantMessage的累积内容逐段渲染出来这正是打字机效果的数据基础——它不是定时器模拟的而是由真实到达的每个数据块驱动的回答进度与网络数据到达节奏完全一致。解析时需要注意 SSEServer-Sent Events的报文格式每个数据块通常以data:开头、以空行分隔块内可能是完整的 JSON也可能被截断解析时需要按\n\n切分事件再逐个提取data字段中的文本增量。这部分解析逻辑要健壮因为后端 ResponseBodyEmitter 应答 推送的数据块边界并不一定与业务语义边界对齐。六、后端与链路支撑ResponseBodyEmitter Nginx 关键配置要让前端流式读取真正成立光有前端还不够整条链路必须全部支持流式任何一环做了缓冲都会破坏渐显效果。这一点在 chatgpt 面试复盘 notes.md 的第10问中有非常完整的说明摘其要点后端接口形态chatgpt-api使用 Spring MVC 提供的ResponseBodyEmitter异步响应协议。当控制器返回ResponseBodyEmitter实例时Spring MVC 开启异步请求处理在单个请求内多次发送 OpenAI 应答数据块——这正是 OpenAI 这类大批量应答数据的理想承载方式Nginx 转发配置由于生产环境接口经 Nginx 转发必须关闭三类默认行为否则数据会被 Nginx 攒批后一次性吐出关闭分块解码chunked_transfer_encoding off;关闭转发缓冲proxy_buffering off;关闭应答缓存proxy_cache off;只有前后端 网关三层都保持流式透传第4节 实现的流式接口才能以打字机效果完整呈现在 第6节 的消息渲染面板中。若读者部署时发现内容一次性出现、没有渐显优先检查的即这三处配置。另外notes.md 还给出了一个实操层面的经验值OpenAI 接口偶发超时因此后端做了熔断6 秒前端也配置了 50 秒的主动断开。原因是ResponseBodyEmitter只要返回了第一个数据块就不算服务端超时但后续数据仍可能卡住前端加主动超时断开更稳妥。这个前端兜底的细节同样可以体现在本章的fetch调用中——给流式读取设置一个最大等待时长超时即中止读取并提示用户。七、实现后的验证与自查清单完成对接后建议按以下步骤验证确保不是看起来像流式而是真的流式跨域验证打开浏览器 DevTools 的 Network 面板确认请求的Access-Control-Allow-Origin响应头与预检OPTIONS请求均正常控制台无 CORS 报错请求体验证确认发送的messages、model、token与界面上的上下文、模型选择、登录状态一致流式验证观察 Network 面板中该请求的响应应看到多条data:分块陆续到达而非单个超大响应体一次性返回渲染验证对话框中的回答逐字/逐段渐显且最终完整内容与一次性请求的结果一致无缺失、无乱码、无截断兜底验证模拟断网或后端卡顿确认前端的超时断开逻辑生效不会出现页面无限等待。八、小结chatgpt-web 第8节流式接口对接 是这套课程中前后端第一次真正打通的关键节点它用fetch解决了请求发送用ReadableStream解决了流式数据读取用 CORS 配置解决了跨域隔离最终把 chatgpt-api 第4节 的ResponseBodyEmitter流式应答渲染成了用户可见的打字机效果。整条链路——前端fetch、后端ResponseBodyEmitter、中间 Nginx 关闭缓冲——环环相扣任何一环攒批都会让渐显效果失效这也是在简历和面试中值得讲透的完整技术点。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐终极指南如何用ThinkPHP 8构建高性能微服务架构终极指南如何用ThinkPHP 8构建高性能微服务架构 ThinkPHP 8作为一款成熟的PHP开发框架为构建分布式Web应用系统提供了强大支持。本文将详细RapidOCR Web服务搭建FastAPI实现OCR接口服务RapidOCR Web服务搭建FastAPI实现OCR接口服务 你是否还在为跨平台OCROptical Character Recognition光学字人工智能计算机视觉OCRClaude Subconscious LETTA_AGENT_ID设置指南如何绑定你自己的Letta智能体Claude Subconscious LETTA_AGENT_ID设置指南如何绑定你自己的Letta智能体 Claude Subconscious 是一款为人工智能AI 应用AI AgentAI 插件Agent 记忆多智能体上一篇3步装好 ExplorerPatcher把 Windows 11 界面调回你熟悉的样子下一篇CANN/asc-devkit asc_int82half函数文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考