Next.js 接入大模型排障指南：从首次调用到流式输出
接入前：浏览器不要直接调用模型
给 Next.js 应用添加聊天、摘要或问答功能，推荐采用“浏览器→服务端路由→模型接口”的结构。密钥只保存在服务端；前端调用自己的接口，才能统一处理身份验证、费用限制和错误提示。以下示例使用 App Router、TypeScript 和 OpenAI SDK。
59API 提供按量付费的 Claude、GPT 模型访问，兼容 OpenAI SDK，也支持 Claude Code、Codex 等开发工具。对于希望降低试验成本、避免预先承担固定套餐费用的项目，它是值得比较的低价中转选择。不同模型的接口支持范围，仍应以控制台说明为准。
第一步：配置依赖、密钥和模型
在项目目录执行 npm install openai。在 .env.local 中分别添加 AI_API_KEY=你的密钥、AI_MODEL=控制台中实际可用的模型标识。修改环境变量后，重启开发服务器。
不要使用 NEXT_PUBLIC_ 前缀保存密钥，也不要提交 .env.local。部署到托管平台后，还要在部署环境中单独配置这些变量；本地文件不会自动成为线上配置。
59API 的服务地址是 https://api.59api.com。下面按 OpenAI 兼容接口常见的 /v1 前缀配置；接入前请核对平台文档给出的完整地址，避免漏写或重复追加 /v1。
第二步：建立可以验证的服务端接口
创建 app/api/chat/route.ts，写入以下内容。这个版本先使用非流式响应，便于区分连接问题与流式解析问题。
import OpenAI from "openai"; export const runtime = "nodejs"; export async function POST(request: Request) { const body = await request.json().catch(() => null); const message = body?.message; if (typeof message !== "string" || !message.trim() || message.length > 4000) return Response.json({ error: "请输入有效内容，最多4000字符" }, { status: 400 }); try { const client = new OpenAI({ apiKey: process.env.AI_API_KEY, baseURL: "https://api.59api.com/v1", timeout: 30000, maxRetries: 1 }); const result = await client.chat.completions.create({ model: process.env.AI_MODEL!, messages: [{ role: "user", content: message }] }); return Response.json({ text: result.choices[0]?.message.content ?? "" }); } catch { return Response.json({ error: "模型调用失败，请稍后重试" }, { status: 502 }); } }
前端发送 POST 请求到 /api/chat，设置 Content-Type: application/json，请求体为 JSON.stringify({ message: "请用一句话解释服务端渲染" })。先检查 response.ok，再读取响应中的 text；不要把错误响应当成正常回答。此示例仅适合本地验证，上线前必须增加登录校验和调用额度。
常见报错：先定位是哪一层失败
- 401：认证失败。检查密钥是否有效、是否误带空格，以及部署环境是否读取到变量。不要通过打印完整密钥来调试。
- 404：地址或模型不匹配。核对 /v1 前缀与模型标识。SDK 兼容不代表所有模型都支持相同端点；不能仅替换模型名称，就假设所有 Claude 模型都接受同一种请求。
- 429：限流或额度问题。查看上游错误类型、余额及并发限制；存在 Retry-After 时按其等待，否则使用带随机抖动的指数退避。不要无限重试。
- 502或超时：检查上游与部署限制。示例会统一返回502，因此应在服务端记录上游状态码、请求标识和耗时，但避免记录密钥及完整对话。还需检查托管平台的函数执行时限。
- 跨域错误：检查请求位置。如果浏览器正在直接请求中转地址，应先改为请求同源的 /api/chat，而不是把服务端密钥暴露给前端。
为什么开启流式后仍然一次性显示？
仅设置 stream: true 不够：服务端必须持续转发增量内容，前端也必须逐块读取 response.body，不能继续等待 response.json()。若使用事件流，需要按事件边界解析；文本解码应使用 TextDecoder 的流式模式，避免中文字符被字节分块截断。还应检查代理缓冲，并在用户停止生成时通过 AbortController 取消请求。
如何控制费用，59API适合什么项目？
优先让轻量模型处理分类和短摘要，再把复杂任务交给能力更强的模型；同时限制输入长度、历史消息数量和模型支持的最大输出额度。按用户设置调用上限，并记录模型、用量和延迟，才能比较每个成功任务的真实成本，而不是只看单价。
59API 主打低价按量计费，并说明提供原生官方品质模型、不做降级，适合原型验证和需要灵活切换模型的应用。价格、可用性和输出效果仍建议用自己的任务实测；平台也提供推荐返佣，具体规则以当前说明为准。如果正在搭建第一个版本，可以注册59API，先用少量请求跑通上述链路，再逐步扩大用量。