data = json.dumps({"content" delta.content})
yield f"a: {data}"
"
" # 创建流式响应，设置正确的Content-Type
response = StreamingHttpResponse(
event_stream(), content_type='text/event-stream'
)
response['Cache-Control'] = 'no-cache'
response['X-Accel-Buffering'] = 'no' # 对Nginx代理很重要
return response
```
这个视图的核心是`event_stream`生成器函数。它发起一个流式请求，然后遍历返回的数据流，每次只取最新产生的文本片段（`delta.content`），并通过SSE格式发送。前端JavaScript可以监听这些事件并实时更新DOM。
前端如何配合？
光有后端流还不够，前端需要能够处理这种持续的数据流。使用`Fetch API`的`ReadableStream`接口是现代而优雅的方式。
```javascript
async function sendMessageStreaming(inputText) {
const response = await fetch('/api/chat/', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({prompt: inputText})
});
const reader = response.body.getReader();
const decoder = new TextDecoder();
let replyBox = document.getElementById('reply');
while (true) {
const {done, value} = await reader.read();
if (done) break;
// 解码并处理接收到的数据块
const chunk = decoder.decode(value);
// 解析SSE格式的“data: {...}”
const lines = chunk.split('"
');
for (const line of lines) {
if (line.startsWith('data: ')) {
const data = JSON.parse(line.substring(6));
replyBox.innerHTML += data.content; // 逐字追加到页面
}
}
}
}
```
这段代码通过`getReader()`读取响应体流，并循环解析从服务器推送过来的每一个数据块，实现真正的“打字机”效果。
部署避坑指南：为何本地成功，上线失效？
很多开发者在本地的`runserver`环境下测试流式响应完美，但一旦使用Nginx + uWSGI/Gunicorn部署后，流式传输就失效了，变成了等待全部完成再一次性返回。这背后主要有两个原因：
1.缓冲区问题：Nginx和uWSGI默认会启用响应缓冲（Buffering），目的是优化静态文件传输。但对于流式响应，缓冲会导致所有数据先在服务器端堆积，直到流结束才发送给客户端。解决方案是在响应头中强制禁用缓冲：
*在Django视图添加：`response['X-Accel-Buffering'] = 'no'`。
*在Nginx配置对应location块中添加：`proxy_buffering off;`。
2.代理超时设置：流式连接可能持续很长时间，如果Nginx或uWSGI的代理超时时间设置过短，会中断长连接。需要适当调高相关配置：
*Nginx: `proxy_read_timeout 300s;`
*uWSGI: `http-timeout = 300`
打造完整的虚拟助手仪表盘
掌握了流式响应的核心后，我们可以构建一个更丰富的项目。参考一个虚拟助手仪表盘的实现，其视图函数不仅处理对话，还可能包含对话历史、用户配置等逻辑。 其结构通常如下：
*视图层 (views.py)：处理核心的聊天请求（支持流式与非流式），管理用户会话。
*模板层 (template)：一个包含输入框、对话历史显示区和实时响应区域的HTML页面。
*路由层 (urls.py)：配置聊天端点和其他辅助页面的URL。
在仪表盘中，你可以进一步集成：
*对话历史管理：使用Django的session或数据库存储用户的多轮对话上下文。
*系统角色预设：让用户选择助手的身份（如“编程专家”、“创意写手”），通过修改发送给API的`system`角色消息实现。
*基础配置界面：让用户调整模型参数，如`temperature`（创造性）和`max_tokens`（回复长度）。
个人观点与选择建议
在我看来，是否采用流式响应应取决于你的应用场景。对于简短、快速的问答，传统同步请求可能更简单直接。但对于长文本生成、代码编写、故事创作等需要较长时间思考的场景，流式响应带来的体验提升是颠覆性的。它把“等待”变成了“观看生成过程”，用户参与感更强。
此外，虽然本文以Django为例，但这一模式是通用的。FastAPI凭借其原生异步支持，在实现流式响应时代码更为简洁高效；而Flask也可以通过生成器实现类似功能。 选择哪个框架，取决于你的团队技术栈和项目对异步并发的要求。
将ChatGPT的智能与Django的稳健相结合，并通过流式响应消除交互延迟，你构建的将不再是一个简单的问答工具，而是一个真正流畅、高效的智能对话界面。从一次性的答案交付转变为持续的对话流，这不仅是技术的升级，更是用户体验哲学的一次转变。尝试从今天这个视图函数开始，让你的应用“流动”起来。
3月23日 
5645 浏览
3月23日 3160 浏览
3月22日 2124 浏览
3月22日 2118 浏览
3月22日 2117 浏览
3月22日 2114 浏览
3月22日 1251 浏览
位置：
版权说明：
