资讯动态

AI SDK 流式响应本地正常但部署后失效怎么排查

发布时间:2026/9/13 23:24:40 来源:尧图企业网站定制
AI SDK 流式响应本地正常但部署后失效怎么排查【免费下载链接】aiThe AI Toolkit for TypeScript. From the creators of Next.js, the AI SDK is a free open-source library for building AI-powered applications and agents项目地址: https://gitcode.com/GitHub_Trending/ai/ai用 AI SDKVercel 出品的 TypeScript AI 工具库开发的应用在本地开发环境里流式输出正常一旦部署界面不再逐字显示而是等待一段时间后一次性返回完整响应。官方排错文档将这一现象列为部署环境常见问题并明确说明此问题的成因多样取决于具体部署环境没有统一根因。本文按照部署场景给出官方文档中给出的排查路径与对应修复配置包括通用部署环境、经过压缩代理的环境以及部署到 Vercel 时的超时截断。先确认现象属于哪一类部署后流式失效的表象都是整段响应延迟返回但文档把根因区分成了三种场景先对照判断一般部署环境本地正常、部署后失效文档未限定具体平台属于content/docs/09-troubleshooting/06-streaming-not-working-when-deployed.mdx描述的通用问题请求经过代理中间件如果应用前面挂了配置了响应压缩compression的代理/中间件流式会失败见 Streaming Not Working When Proxied部署在 Vercel 且响应被截断长回复在 UI 中被截断Vercel 日志出现 timeout或前端报错Uncaught (in promise) Error: Connection closed见 Getting Timeouts When Deploying on Vercel。注意第 3 类与前一类的表象不同前两类是响应完整但不再逐字显示Vercel 超时类则是响应被中途切断。先确定属于哪一类再执行对应修复。通用部署环境为流式响应添加分块传输头针对本地正常、部署后失效的通用场景官方给出的处理方式是给流式响应添加Transfer-Encoding: chunked和Connection: keep-alive请求头。修改点在返回流式响应的服务端代码里给createUIMessageStreamResponse的headers参数可选参数类型为Headers | Recordstring, string加上这两个头return createUIMessageStreamResponse({ stream: toUIMessageStream({ stream: result.stream }), headers: { Transfer-Encoding: chunked, Connection: keep-alive, }, });其中result是流式调用如streamText的返回值result.stream交给toUIMessageStream转换为 UI 消息流createUIMessageStreamResponse与toUIMessageStream均从ai包导入import { createUIMessageStreamResponse, toUIMessageStream } from ai。这个函数创建向客户端流式推送 UI 消息的Response对象参数详情见 createUIMessageStreamResponse API 参考。文档原文用的是you can try the following即这是建议尝试的修复项而非保证覆盖所有部署环境的结论。经过压缩代理时声明不压缩如果请求链路中存在配置了响应压缩的代理中间件压缩会导致流式失败。修复方式是给流式 API 的响应加上Content-Encoding: none头return createUIMessageStreamResponse({ stream: toUIMessageStream({ stream: result.stream }), headers: { Content-Encoding: none, }, });文档特别注明该方案只影响流式 API 的响应不改动代理对其他接口的处理因此可以直接对当前任务放心使用。如果你的环境既经过代理、又有前述通用部署问题两个头可以同时出现在headers里。部署在 Vercel处理函数超时截断当现象是长回复被截断、Vercel 日志出现 timeout、前端报Uncaught (in promise) Error: Connection closed时问题出在函数执行时长上。使用 Vercel Fluid Compute 时所有套餐的默认函数执行时长是 5 分钟300 秒文档认为这对多数流式应用已经足够需要更长超时时再提高maxDuration。Next.jsApp Router项目在路由文件route file或调用 Server Action 的页面中添加export const maxDuration 600;其他框架在vercel.json中按路由配置超时{ functions: { api/chat/route.ts: { maxDuration: 600 } } }上例中的api/chat/route.ts与600是文档示例值替换为你实际的流式接口路径和需要的秒数。文档对maxDuration的限制如下调整前需核对套餐套餐最大执行时长Hobby最高 300 秒5 分钟Pro最高 800 秒约 13 分钟Enterprise最高 800 秒约 13 分钟把maxDuration设置到超过 300 秒需要 Pro 或 Enterprise 套餐Hobby 套餐无法通过该配置突破 300 秒上限。如何验证修复生效成功条件与故障现象相对部署环境中的应用恢复逐字增量显示而不再等待一段时间后一次性返回完整响应如果属于 Vercel 超时场景则长回复不再被截断Vercel 日志不再出现 timeout前端不再报Uncaught (in promise) Error: Connection closed。两点边界需要记住一是文档明确成因取决于部署环境若添加请求头后仍未恢复流式说明你的部署链路还有其他未覆盖的环节官方文档未给出进一步的统一排查顺序二是本文各修复项对应各自场景不要脱离对应现象盲目套用例如没有代理压缩的环境无需Content-Encoding: none没有 Vercel 超时现象的部署无需调整maxDuration。【免费下载链接】aiThe AI Toolkit for TypeScript. From the creators of Next.js, the AI SDK is a free open-source library for building AI-powered applications and agents项目地址: https://gitcode.com/GitHub_Trending/ai/ai创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价