什么是流式输出,后端怎么生成,前端怎么渲染

什么是流式输出,后端怎么生成,前端怎么渲染

流式输出(Streaming Output) 就像是在看视频直播,内容是一边产生一边传输给你的,而不是像下载电影那样,必须等整个文件下完才能开始看。

在 AI 领域(比如 ChatGPT),流式输出表现为文字一个接一个地“蹦”出来,而不是转半天圈圈后突然甩出一大段话。


什么是流式输出,有什么特点

1. 它是怎么实现的?

流式输出的核心技术通常是 SSE (Server-Sent Events,服务器发送事件)

在传统的 HTTP 请求中,模式是“一问一答”:客户端发请求,服务器处理完全部逻辑,打成一个大包发回客户端。而在流式输出中,过程如下:

  1. 建立持久连接:客户端发送一个请求,并在 HTTP 头部声明 Accept: text/event-stream
  2. 分块传输:服务器每生成一个字(或一个 Token),就立即将其封装成一个小数据块发送出去。
  3. 保持连接:直到内容生成完毕,服务器才会发送一个特殊的结束标志(如 [DONE]),随后关闭连接。

2. 流式输出的特点

特点说明
低首字节延迟 (TTFB)用户能瞬间看到反馈,大大缓解了等待焦虑。
实时性适合长文本生成。如果是普通模式,生成 1000 字可能需要 20 秒,流式模式下第 1 秒就开始显示。
单向通讯不同于 WebSocket 的双向奔跑,SSE 主要是服务器向客户端“单向投喂”数据。
资源占用因为要长时间维持一个 HTTP 连接,对服务器的并发处理能力有一定要求。

3. 为什么 AI 必须用它?

大语言模型(LLM)的推理过程是自回归的。简单来说,它每生成一个词,都要基于前面所有的词重新算一遍概率。

P(wt+1∣w1,w2,...,wt)P(w_{t+1} | w_1, w_2, ..., w_t)P(wt+1​∣w1​,w2​,...,wt​)

这个过程本身就很耗时。如果等 2000 个 Token 全部算完再给用户,用户可能以为网页卡死了。流式输出完美契合了模型“一个一个词往外蹦”的运行逻辑。

后端怎么实现

在后端实现流式输出,本质上是打破“处理完全部逻辑再返回”的传统模式,改为利用 HTTP 分块传输(Chunked Transfer Encoding) 持续向客户端推送数据。

最常见的方法是使用 SSE (Server-Sent Events)。下面我以 Python (FastAPI) 和 Node.js (Express) 为例展示核心逻辑。


1. Python 实现 (以 FastAPI 为例)

FastAPI 内置了 StreamingResponse,非常适合配合大模型的生成器(Generator)使用。


2. Node.js 实现 (以 Express 为例)

在 Node.js 中,通过手动设置 HTTP 响应头并使用 res.write() 来持续发送数据。


3. 实现的关键要素

要确保后端流式输出成功,必须满足以下几个条件:

  • 正确的 Content-Type: 必须设置为 text/event-stream
  • 禁用缓冲 (Buffering):
    • 如果你使用了 Nginx 等反向代理,它可能会默认缓存后端的数据,攒够一波再发给前端。
    • 解决方法: 在 Nginx 配置中设置 proxy_buffering off;,或者让后端返回 X-Accel-Buffering: no 响应头。
  • 特定的数据格式:
    • 每条消息必须以 data: 开头。
    • 每条消息必须以两个换行符 \n\n 结尾。

4. 进阶:如何对接大模型 (LLM)

如果你是在调用 OpenAI 或 Anthropic 的 API,它们通常提供 stream=True 参数。你的后端实际上充当了一个中转站(Proxy)

  1. 后端调用 AI API(开启流式)。
  2. 后端迭代接收 AI 返回的每一个 Chunk。
  3. 后端立刻将这个 Chunk 转发给前端。

前端怎么实现

在前端捕获流式数据,主要有两种主流方案:传统的 EventSource 和现代的 fetch + ReadableStream

由于现在的 AI 接口(如 OpenAI)大多使用 POST 请求,方案二 (fetch) 是目前最通用的做法。


方案一:使用 fetch 结合 ReadableStream (推荐)

fetch API 本身支持流式读取。通过 response.body,你可以获取一个读取器(Reader),逐块解析数据。


方案二:使用 EventSource (仅限 GET)

如果你的后端接口支持 GET 请求,EventSource 是最简单的原生实现,它会自动处理重连和心跳。


核心难点:如何优雅地“渲染”?

在处理 AI 流式输出时,你可能会遇到以下两个坑:

  1. Markdown 渲染:数据是一点点出来的,如果你每出一个字就渲染一次 Markdown,性能会炸掉。
    • 对策:使用带缓存的渲染库(如 markdown-it),并限制渲染频率(如 100ms 刷新一次)。
  2. 数据截断:有时候一个 Unicode 字符或者一个 JSON 字符串会被拆分到两个不同的 Data Chunk 中。
    • 对策:在前端维护一个缓冲区(Buffer),将接收到的 value 累加,直到匹配到完整的 \n\n 再进行解析。

Read more

AI 直接生成前端代码:我的软件原型设计流,从此告别重复画图

AI 直接生成前端代码:我的软件原型设计流,从此告别重复画图

近年来,AI 辅助开发越来越成熟,尤其是在快速原型设计方面。今天分享一下我如何借助 Cursor、Trace solo、ChatGPT、Qoder 等 AI 工具,高效完成软件原型的自动绘制与代码生成。 📌 核心流程三步走 1️⃣ 用 AI 输出需求文档(非技术描述) 首先,我会让 AI 根据产品思路或功能描述,生成一份清晰、无技术细节的需求文档。这一步不写代码,只聚焦逻辑与用户流程。 2️⃣ AI 生成 HTML 原型代码 基于上一步的需求文档,直接让 AI 生成对应的 HTML 代码,快速搭建出可交互的前端原型。支持实时预览,直观看到界面效果。 3️⃣ 反复微调,直至满意 生成的原型往往需要多次调整。通过自然语言描述修改方向,AI 可快速迭代代码,直至达到想要的交互与视觉效果。

【Python 爬虫】Playwright 多浏览器并发实战:Chromium/Firefox/WebKit 性能对比与优化

1. 为什么你需要多浏览器并发爬虫? 如果你只用过单浏览器爬虫,可能会觉得“一个浏览器不就够了吗?”。我以前也是这么想的,直到在一个真实项目里踩了坑。当时我需要从几个大型电商网站抓取价格数据,一开始只用 Chromium,跑得挺快。但没过多久,网站的反爬机制就启动了,不仅速度变慢,还频繁弹出验证码。更头疼的是,我发现有些页面在 Firefox 上渲染出来的商品列表结构,和 Chromium 里看到的不太一样,导致我写好的定位器失效了。 这就是单浏览器的局限性:容易被识别、兼容性有盲区、性能瓶颈单一。而 Playwright 原生支持 Chromium、Firefox 和 WebKit 三大引擎,这不仅仅是“多一个选择”,而是给了我们一套组合拳。你可以把爬虫任务想象成一支特种部队:Chromium 像突击手,速度最快,生态工具最全;Firefox 像侦察兵,在某些反爬策略下更隐蔽;WebKit 则像特工,能模拟 Safari

网站检测不用等! Web-Check+cpolar让异地协作查漏洞更高效

网站检测不用等! Web-Check+cpolar让异地协作查漏洞更高效

文章目录 * 前言 * 1.关于Web-Check * 2.功能特点 * 3.安装Docker * 4.创建并启动Web-Check容器 * 5.本地访问测试 * 6.公网远程访问本地Web-Check * 7.内网穿透工具安装 * 8.创建远程连接公网地址 * 9.使用固定公网地址远程访问 前言 Web-Check 是一款全方位的网站诊断工具,能检测 IP 信息、SSL 证书、DNS 记录、开放端口等关键数据,适合开发者做性能优化、运维人员做安全巡检,还能帮安全测试人员识别潜在风险。它的优点是结果可视化强,所有数据在仪表盘分类呈现,不用手动整合多工具报告,省时又清晰。 用 Web-Check 时发现,检测前最好确认目标网站能正常访问,否则可能出现数据不全;另外,生成的报告里有不少专业术语,新手可以先查基础概念(比如 SSL 链、DNS

C++ 方向 Web 自动化测试实战:以博客系统为例,从用例到报告全流程解析

C++ 方向 Web 自动化测试实战:以博客系统为例,从用例到报告全流程解析

🔥草莓熊Lotso:个人主页 ❄️个人专栏: 《C++知识分享》《Linux 入门到实践:零基础也能懂》 ✨生活是默默的坚持,毅力是永久的享受! 🎬 博主简介: 文章目录 * 前言: * 一. 自动化测试前置:明确测试范围与测试用例设计 * 二. 自动化测试脚本开发:Python+Selenium 实现 * 2.1 通用工具类:common/Utils.py * 2.2. 登录模块测试:cases/BlogLogin.py * 2.3. 博客列表与详情页测试:cases/BlogList.py & BlogDetail.py * 2.3.1. 列表页测试(BlogList.py) * 2.3.