Next.js 为什么成为 AI 应用的默认框架？不是因为炒作

Next.js 13 之前，构建 ChatGPT 风格的界面只有两条路：让用户盯着空白屏幕等十几秒，或者搭一套自定义 WebSocket 服务器并承担全部复杂度。大多数团队两件事都没做好，AI 产品在演示视频里流畅，在生产环境里卡顿。

Next.js 13 把服务端流式传输变成框架的一等能力，AI 应用开发体验从此开始好用。其他的事情都从这里延伸出来。

流式传输解决的是延迟，不只是视觉效果

开发者有时描述流式传输是"让文字一个字一个字出现的东西"，这只是表面现象。LLM 按 token 顺序生成响应，计算过程本身是串行的，没有一个现成的答案在等着发送。流式传输让用户在计算过程中就能看到输出，短响应省两秒，一个需要三十秒生成的复杂响应，有没有流式传输是可用和卡死之间的差距。

Next.js 13 的 App Router 让流式传输成为内置能力，Vercel 的 AI SDK 在上面封装了 useChat 和 useCompletion 钩子，处理流式连接、累积 token、管理 UI 状态，OpenAI、Anthropic、Mistral 通过同一个接口接入。

打字效果之外，流式传输让部分渲染成为可能：文档一节一节呈现，结构化输出的字段在被填充时逐步展示，推理过程实时显示。等完整响应回来再渲染的架构里，这些都做不到。

服务端组件省掉了一整个后端层

服务端组件之前，构建 API 密钥安全的 AI 应用需要独立后端：一个 Express 或 FastAPI 服务器坐在 React 前端和 LLM 之间专门做中转，否则前端直接调 LLM 会把凭据暴露给浏览器。

服务端组件在大多数场景下把这个中间层省掉了。跑在服务端组件里的代码在服务器执行，不下发到客户端，API 密钥留在服务器，LLM 直接从组件里调用。

对内部工具和原型：一个 Next.js 应用，没有单独后端部署，没有前后端 API 契约需要维护，工程量减少很多。

对有真实复杂度的生产系统，运转良好的模式：服务端组件处理准备工作（加载用户上下文、拉取相关数据、拼提示词），把整理好的数据传给处理流式输出和交互的客户端组件，AI 处理留在服务端，实时更新经由流式传输来。

API 路由当代理后端，原因比想的简单

Next.js API 路由（/app/api/*/route.ts）是构建代理编排逻辑的合理位置，原因很实际：它和前端代码共享代码库，在早期开发阶段省去了大量跨服务的协调成本。TypeScript 类型定义一次，流经 UI 代码和代理代码；整体作为一个单元部署；本地开发只起一个进程。

路由处理器原生支持流式响应，包括多步骤代理工作流。跑工具调用，在更多工作进行时把中间结果流给客户端，完成后关闭连接，用户全程看到进度。

部署超时是很多团队没想到的问题

标准 Serverless 函数超时在 10 到 30 秒之间。LLM 调用需要时间，多步骤代理工作流需要更多时间，两个约束相交，会在最意外的时候暴露成部署故障。

Vercel 构建了 Next.js，刻意处理了这个：流式连接可以保持超过标准函数超时的时间，边缘函数全球分发降低延迟，基础设施为 AI 应用的使用模式设计。

其他平台（Railway、Fly.io、Render、AWS）都有可用的 Next.js 支持。构建任务时长较长的代理工作流时，在出问题之前先检查你的部署平台的超时限制。

什么时候不该选 Next.js

纯 API 后端，没有 UI：FastAPI 或 Express 更直接，部署体积更小，功能集更合适。

不熟悉框架的小团队：App Router、服务端组件、客户端组件、服务端操作、边缘运行时各有不同的心智模型和限制，学习曲线是真实的。一个简单的 AI API 服务用 Next.js 构建，会带着和需求不匹配的框架复杂度。

大规模实时双向通信：高吞吐并发流式连接、实时协作功能，需要独立的 WebSocket 层；Next.js 可以发起和接收流，但不是为这种场景设计的。

它好用的地方：需要 UI、调 LLM、管状态、处理认证、可靠部署的 AI Web 产品。这个需求范围内，权衡说得过去，生态足够密集，从想法到上线的时间比大多数替代方案短。这是它反复胜出的实际原因。