🚀 别让用户等得想摔手机 | 手把手教你实现打字机效果
“点发送，转圈圈，十秒后哗啦蹦出一大段”——这体验简直像回到拨号上网时代。用户早没了耐心，老板也皱眉头。“这玩意儿是人工智障吗？半天憋不出一句话！”
后来我把接口改成了流式输出（Streaming Output），效果瞬间起飞，用户都说“哇，像真人打字一样”。今天咱们就聊聊在FastAPI里怎么实现这种丝滑的“打字机”效果，顺便把我当初翻车的几个点也抖出来，让你少走弯路。
🤔 问题：为什么你的AI接口像个树懒？
传统的API响应是“攒够了再给你”：AI模型把所有字都生成完了，后端一次性把整个JSON返回给前端。这就好比你去餐厅点餐，厨师必须把整桌菜全做完才一起端上来，第一道菜都凉了。
用户看着空白的页面，焦虑感爆棚。而流式输出的思路是：“边生成边推送”——模型每吐出一个字，就立刻通过同一个HTTP连接发到前端，前端逐字显示。用户看着文字一个个蹦出来，心理等待时间至少缩短一半。
那在FastAPI里怎么搞？其实核心就两个关键词：async generator 和 StreamingResponse。
⚙️ 原理：把API变成“水龙头”
你可以把FastAPI的普通响应想象成一个密封的水瓶，必须装满才能递给你；而流式响应是一个开着的水龙头，随时拧开随时流水。背后用的是HTTP的分块传输编码（chunked transfer encoding），连接不断开，数据一块一块地发。
FastAPI 的StreamingResponse就是专门干这个的。它接收一个异步生成器（async generator），生成器每 yield 一段数据，FastAPI 就立刻把它推给客户端。
🔨 实战：手写一个流式AI接口
假设我们用的是OpenAI的流式API（或者任何兼容的模型），后端Python代码可以这么写：
from fastapi import FastAPI, Request
from fastapi.responses import StreamingResponse
from openai import OpenAI
import asyncioapp = FastAPI()
client = OpenAI(api_key="your-key") # 正式项目请用环境变量async def generate_stream(prompt: str):try:# 调用OpenAI的流式接口stream = client.chat.completions.create(model="gpt-3.5-turbo",messages=[{"role": "user", "content": prompt}],stream=True, # 关键！开启流式)for chunk in stream:# 逐字提取内容，注意判空if chunk.choices and chunk.choices[0].delta.content:content = chunk.choices[0].delta.content# yield 出去，前端就会收到一个 data: {...}yield f"data: {content}\n\n"await asyncio.sleep(0.02) # 模拟打字间隔，非必须except Exception as e:yield f"data: [ERROR: {str(e)}]\n\n"finally:# 发送结束标志，很多前端SSE库靠这个判断结束yield "data: [DONE]\n\n"@app.post("/chat")
async def chat_endpoint(request: Request):data = await request.json()prompt = data.get("prompt", "")return StreamingResponse(generate_stream(prompt),media_type="text/event-stream" # 重要！告诉浏览器这是SSE流)前端代码（比如用EventSource或者fetch的流式读取）我就不贴了，网上大把。但是——这里至少有四个坑，我一个个替你踩过了：
💥 坑1：CORS 跨域
如果你前端跑在 localhost:3000，后端是 8000，没配CORS你连个毛都收不到。FastAPI 用 fastapi.middleware.cors.CORSMiddleware 加上，别偷懒！
⏱️ 坑2：超时设置
默认网关或反向代理（比如Nginx）的超时可能只有60秒，AI生成长篇内容容易断流。记得调大 proxy_read_timeout 和 keepalive_timeout，我直接设到了300秒。
🧩 坑3：数据格式要规范
上面的代码我用了 SSE 格式 data: ...\n\n，很多前端库（比如@microsoft/fetch-event-source）必须按这个解析。如果你随便yield一个JSON，前端可能直接报错。
📦 坑4：生成器里的异常处理
API key过期、模型限流、网络抖动……任何异常没捕获，连接就会突然中断，用户只看到一半。一定要 try...finally，要么发错误信息，要么发 [DONE] 标记。
🎯 进阶：让流式更“像人”
你以为能吐出字就完了？想做得更逼真，还有几个小技巧：
🔹 用 asyncio.sleep 控制速度
真实人打字是有停顿的，特别是中英文混输。我习惯在每句话结束或标点后加个0.05秒的sleep，体验瞬间细腻。
🔹 缓存首字，极速响应
有时候模型“冷启动”要一两秒，用户以为挂了。可以先从缓存里拿一个固定的开头（比如“好的，我来帮你……”）立刻发出去，同时后台继续生成。这个“首字优化”能让感知延迟降为0。
🔹 结合Server-Sent Events (SSE) 还是 WebSocket？
如果只是AI单方面推送，SSE（也就是上面的 text/event-stream）完全够用，轻量级。如果要双向频繁交互（比如游戏），才上WebSocket。
⚠️ 最后啰嗦一句：
千万别在线上环境把API Key硬编码在代码里！用环境变量，用密钥管理服务。我有个朋友（真的不是我）把key传到GitHub公开仓库，几分钟后收到账单短信，人都傻了。还有，流式输出一定要加速率限制，防止恶意用户用“打字机”刷爆你的token。
好啦，今天这波操作你get到了吗？赶紧去给你的AI应用装个“打字机”皮肤，用户反馈绝对up up！
如果你在实现中遇到怪问题，比如“明明后端打印了字，前端就是不显示”，大概率是换行符没处理好，或者Nginx缓冲了响应——记得关掉 proxy_buffering。
对了，顺手点个⭐收藏吧，下次遇到流式相关的坑，翻出来看一眼，肯定能救急。也欢迎在评论区甩出你的翻车经历，咱们一起乐呵乐呵～
—— 你的老朋友，一名程序媛 👩💻