网关密钥只放一份，放在 Next.js 路由处理程序里
带小团队接 AI 能力时，最常见的失控点不是代码写不出来，而是密钥到处都是：前端硬编码一份、测试脚本里一份、某个同事的本机 .env 又一份。谁都能调、谁都不知道花了多少、谁也说不清线上到底走的哪个模型。
这篇文章讲一个最小但能落地的方案：把所有 AI 网关请求收敛到 Next.js 的路由处理程序（Route Handler）里，前端只跟自己的后端说话。以 ThisToken.AI 这类聚合网关为例，走一遍注册、拿 Key、跑通第一段代码、再补上团队协作和风控的完整流程。
为什么是路由处理程序，而不是前端直连
如果你在浏览器里直接调用大模型 API，密钥就必须暴露在客户端——这等于把公司银行卡贴在公告栏上。而且一旦换供应商、调限流、加审计日志，你要改动散落在各个页面的调用点。
路由处理程序的价值在于它是天然的「收口」：
- 密钥只存在服务端，通过环境变量注入，永远不出现在浏览器；
- 换模型、换供应商只改一处，前端接口保持稳定；
- 用量、错误、审计都在一个位置可观测，方便对账。
对小团队来说，这意味着「谁负责什么」变得清楚：前端同学负责界面，后端路由负责模型，管理者在网关后台看账单。
第一步：注册并获取 API Key
- 打开 ThisToken.AI 官网，注册一个团队账号；
- 进入控制台，创建一个 API Key，只给它需要的权限范围；
- 把 Key 配置到项目根目录的
.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 BASE_URL = "https://api.thistoken.ai/v1";
export async function POST(req: NextRequest) {
try {
// 1. 鉴权：示例用简单 token，正式项目建议接你自己的用户体系
const auth = req.headers.get("authorization");
if (auth !== `Bearer ${process.env.APP_INTERNAL_TOKEN}`) {
return NextResponse.json({ error: "unauthorized" }, { status: 401 });
}
// 2. 只透传白名单字段，别把前端传来的整个对象直接转发
const body = await req.json();
const payload = {
model: body.model ?? "gpt-4o-mini",
messages: body.messages,
max_tokens: Math.min(body.max_tokens ?? 500, 1000),
};
// 3. 真正的网关调用
const upstream = await fetch(`${BASE_URL}/chat/completions`, {
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${process.env.THISTOKEN_API_KEY}`,
},
body: JSON.stringify(payload),
});
if (!upstream.ok) {
// 不要把上游原始错误直接抛给前端，避免泄露细节
console.error("gateway error:", upstream.status);
return NextResponse.json({ error: "upstream_error" }, { status: 502 });
}
const data = await upstream.json();
return NextResponse.json({
reply: data.choices?.[0]?.message?.content ?? "",
});
} catch (e) {
console.error("route error:", e);
return NextResponse.json({ error: "internal_error" }, { status: 500 });
}
}前端调用就非常干净了：
const res = await fetch("/api/chat", {
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${process.env.NEXT_PUBLIC_APP_INTERNAL_TOKEN}`,
},
body: JSON.stringify({
messages: [{ role: "user", content: "帮我总结这段周报" }],
}),
});
const { reply } = await res.json();本地 npm run dev 后用 curl 或页面打一次 /api/chat，收到 reply 字段就算跑通了。
管理者要盯的三件事
代码跑通只是开始，流程上建议把责任落到人头。
密钥有唯一的Owner。 网关 Key 只有一份，存在团队密码管理器里，由一个人负责轮换。路由处理程序从 process.env 读取，任何人都不能把 Key 写进代码或前端。发现泄露的标准动作是：立即在控制台吊销 → 换新 Key → 更新部署环境变量，全程不超过十分钟。
额度有上限。 在网关后台设置消费限额，同时在路由里做服务端兜底——上面代码里的 max_tokens 上限就是第一道闸门。如果某个功能被刷，损失被锁在一个可预期的范围内。预算烧穿还在跑的事故，多数是因为没人提前定「多少算太多」。
用量有人对账。 每周花五分钟看一次网关后台的调用量，和业务量做个粗略匹配：日活没涨但调用翻倍，大概率是死循环或前端重复请求。聚合网关的好处是所有模型的账单都在一处，不用挨个供应商后台去翻。
团队协作约定
三条就够：
- 前端禁止直连任何模型 API，所有 AI 调用必须经过
app/api/下的路由； - 新增模型走配置，不走硬编码——把 model 名放进环境变量或配置表，切换不用发版；
- Code Review 必查两件事：有没有密钥被带进客户端代码、有没有没做上限的透传参数。
这套约定很小，但它把「AI 能力」从个人手艺变成了团队资产：人走了代码还在，密钥轮换不影响业务，账单看得明白。
结语
Next.js 的路由处理程序本质上就是一段跑在服务端的函数，用它做 AI 网关的统一入口，成本几乎为零，收益却是密钥安全、可审计、可替换三件事一起解决。独立开发者的第一段代码，从这里开始跑通就够用了：先注册账号 → 拿到 API Key → 复制上面的路由代码 → 本地打一次请求，十分钟后你的 AI 应用就有了第一道正经的门卫。
如果你还没有账号，可以直接在这里注册开始：https://api.thistoken.ai/register
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。