把AI网关放进Next.js路由处理程序 - 小团队上线前的三道检查
为什么管理者应该关心“请求写在哪里”
很多小团队接AI能力的第一版代码，是把API调用直接写在前端组件里：页面一加载，浏览器直接请求模型服务商。跑是能跑通，但上线第二天你就会面对几个绕不开的问题：
- API Key暴露在客户端，任何人打开浏览器开发者工具都能拿走；
- 调用没有统一的日志和用量统计，月底账单对不上号；
- 换模型供应商要改十几处代码，谁也不敢动。
这些都不是“程序员技术问题”，而是流程与风险问题。解决思路也很朴素：所有AI请求都经过自己服务器的一道“闸口”——在Next.js里，这道闸口就是 Route Handler（路由处理程序）。网关服务（比如 ThisToken.AI 这类聚合多家模型的API平台）配合这个闸口，能让团队统一管住Key、统一记账、统一换模型。
本文带你走完三步：注册网关拿Key → 写第一个代理接口 → 上线前做一次风险检查。
第一步：注册ThisToken.AI，拿到API Key
- 打开 ThisToken.AI 官网，注册一个团队账号（而不是用个人邮箱随手注册——后面要给同事分配权限）；
- 进入控制台的 API Keys 页面，创建一个Key，命名建议直接写用途，如
prod-nextjs-gateway； - Key只在创建时完整展示一次，立刻放进密码管理器或团队密钥库；
- 记下统一入口地址：
https://api.thistoken.ai/v1——所有模型的请求都走这一个地址，后面换模型不用改域名。
费用方面以官网价格页为准，这里不展开数字。建议管理者第一次充值时额度设小一点，先跑通再放量。
第二步：写第一个代理接口
环境变量（.env.local，务必加进 .gitignore）：
THISTOKEN_API_KEY=sk-xxxxxxxxxxxxxxxx创建 app/api/chat/route.ts：
// app/api/chat/route.ts
import { NextRequest, NextResponse } from "next/server";
const GATEWAY_BASE_URL = "https://api.thistoken.ai/v1"; // 统一网关入口
export async function POST(req: NextRequest) {
try {
const { messages } = await req.json();
// 简单的输入校验：别让脏数据烧钱
if (!Array.isArray(messages) || messages.length === 0) {
return NextResponse.json({ error: "参数不合法" }, { status: 400 });
}
const upstream = await fetch(`${GATEWAY_BASE_URL}/chat/completions`, {
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${process.env.THISTOKEN_API_KEY}`,
},
body: JSON.stringify({
model: "gpt-4o-mini", // 换模型只改这一行
messages,
max_tokens: 1000,
}),
});
if (!upstream.ok) {
// 记录日志但不把上游错误细节原样抛给前端
console.error("[gateway] 上游返回", upstream.status);
return NextResponse.json({ error: "AI服务暂时不可用" }, { status: 502 });
}
const data = await upstream.json();
return NextResponse.json({ reply: data.choices?.[0]?.message?.content ?? "" });
} catch (e) {
console.error("[gateway] 请求异常", e);
return NextResponse.json({ error: "服务器内部错误" }, { status: 500 });
}
}前端调用就变成普通的内部请求：
const res = await fetch("/api/chat", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ messages: [{ role: "user", content: "你好" }] }),
});启动 npm run dev，访问页面上发一条消息，能看到回复就算跑通了。
Python侧如果后端另用脚本验证，同样的写法是：
from openai import OpenAI
client = OpenAI(
api_key="sk-xxxxxxxx",
base_url="https://api.thistoken.ai/v1", # 网关统一入口
)
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "你好"}],
)
print(resp.choices[0].message.content)第三步：上线前的三道检查（给管理者）
1. Key是否只在服务端？ 全局搜一遍代码，确认API Key只出现在 process.env，前端bundle里搜不到。网关控制台里也建议为开发、生产环境各建一个Key，泄露时可以单独吊销。
2. 用量是否可追溯？ 在Route Handler里加一行日志（用户ID、模型、token数），配合网关控制台的调用记录，每周对一次账。上线初期最怕的不是贵，而是不知道贵在哪。
3. 换模型是否只改一行？ 因为所有请求都走 https://api.thistoken.ai/v1 这一个入口，切模型只是改 model 字符串。建议把模型名也放进环境变量，切换时不用改代码、不用重新部署，评审成本低很多。
常见的两个坑
- 没加输入校验：用户传个超大messages数组，token直接烧爆。务必限制长度和条数。
- 把上游错误原样透传：上游报错信息里可能包含你的Key前缀等敏感内容，统一包装成友好提示，细节只进服务端日志。
小结
把AI请求收口到Next.js路由处理程序，本质上是给团队立了一条规矩：Key不落地、调用留痕、换模型不动架构。这套东西越早建，后面人越多越省事。还没注册网关账号的，可以从这里开始：https://api.thistoken.ai/register
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。