密钥：那把不能进前端的钥匙

一句话

你写在前端代码里的任何东西，全世界都能看到。包括你以为藏起来的那个 API Key。

先搞清楚什么是「密钥」

密钥（key / token / secret / 凭证）就是你向某个服务证明「我是我」的那串字符。

常见的有：

• OpenAI / Claude 的 API Key（拿它就能用你的钱调 AI）
• 数据库连接串（拿它就能读写你的数据）
• 云服务的 access key（拿它能干的事更多）
• 短信、支付、邮件服务的密钥（拿它能以你的名义发东西、收钱）

它们的共同点：谁拿到，谁就是你。

为什么 AI 特别容易在这栽

你跟 AI 说：「帮我接一下 OpenAI，让用户能在页面上问问题。」

AI 会给你一段能跑的代码。**它确实能跑。**在你电脑上完美工作。

但它八成会把 Key 直接写进前端——因为那是最短、最直接、最容易跑通的写法。AI 优化的是「能跑」，不是「能上线」。

这不是 AI 的错

你没说「这要上公网」，它就默认你在本地玩。

**它给的是你要的东西，不是你需要的东西。**这个区别贯穿整个 L5 和 L6——你不说，它不会替你想。

前端和后端，一句话说清

	代码在哪运行	谁能看到代码
前端	用户的浏览器里	所有人
后端	你的服务器上	只有你

这是全部的关键。前端代码必须先下载到用户电脑上才能运行——这是浏览器的工作原理，无法改变。

所以任何「藏在前端」的想法都是幻觉：

• ❌ 写在变量里 → 能看到
• ❌ 混淆压缩过 → 能看到（搜一下就还原了）
• ❌ 拆成几段拼起来 → 能看到
• ❌ 存在 .env 文件里但被打包进前端 → 能看到（这个最坑，下面单讲）

最坑的一种：.env 的假安全感

很多人以为把 Key 放进 .env 文件就安全了，因为「.env 不进 git」。

但打包工具会把带特定前缀的变量塞进前端产物里。

框架	这个前缀 = 会进前端 = 全世界可见
Vite / Astro	PUBLIC_ 、VITE_
Next.js	NEXT_PUBLIC_
Create React App	REACT_APP_
Nuxt	NUXT_PUBLIC_

这些前缀的存在，就是为了「我知道这个会公开，我故意的」。

所以看到 NEXT_PUBLIC_OPENAI_API_KEY 这种东西——那个 Key 已经公开了，.env 一点忙都没帮上。

正确的做法

让密钥只待在后端，前端向你自己的后端要东西。

❌ 危险
浏览器 ──(带着你的 Key)──> OpenAI
        ↑ Key 在这里，所有人可见

✅ 安全
浏览器 ──(不带 Key)──> 你的后端 ──(带 Key)──> OpenAI
                       ↑ Key 只在这里，用户看不到

跟 AI 提需求时，把这句话加上：

密钥必须只在服务端使用，前端不允许出现任何 API Key。请用服务端路由/API route 做一层代理，前端只调我自己的接口。

顺带解决另一个问题

加了这层代理之后，你还顺手获得了限流的能力——可以限制每个用户每天能调几次。

否则有人拿到你的接口猛刷，账单一样会爆，只是慢一点。这条属于上线清单第 6 条。

自己动手查：三分钟

不要相信任何人说「应该没问题」，包括 AI，包括我。自己查。

查法一：搜前端产物

构建之后，在产物目录里搜你的 Key：

# 把 dist 换成你的构建输出目录（可能是 build / .next / out）
grep -r "sk-" dist/ 2>/dev/null
grep -riE "api[_-]?key|secret|token|password" dist/ 2>/dev/null | head -20

**搜到了 = 已经泄露。**没搜到再往下。

查法二：浏览器 Network 面板

1. 打开你部署好的站
2. 按 F12（Mac 上 Cmd+Option+I），切到 Network 标签
3. 刷新页面，正常用一遍所有功能
4. 挨个点开请求，看 Headers 和 Response

任何一处出现你的 Key = 泄露。

为什么强调这一步

这是被最多人用来「捡」别人密钥的方式——不需要任何技术，打开浏览器就能做。

有人把这个操作录成视频发到网上，几千人点赞。那视频里演示的每一个受害者，都以为自己的 Key 藏好了。

查法三：git 历史

Key 有没有在某次提交里进过仓库？

git log -p --all -S "sk-" 2>/dev/null | head -40

如果查出来了

删掉代码里的 Key 是不够的。 git 历史还留着，公开仓库的话早就被爬走了。

正确顺序：

1. 立刻去服务商后台把那个 Key 作废（revoke） ← 先做这个
2. 生成新 Key，按上面的正确做法放到后端
3. 再考虑清理 git 历史（麻烦，但第 1 步做了就不紧急了）

**顺序不能反。**先清历史再作废，中间那段时间 Key 仍然有效。

真实代价

• 有人把云服务密钥推进了 GitHub 公开仓库，被人拿去跑算力，账单 55,444 美元
• 有人在前端硬编码了数据库凭证，被人在 Network 面板直接捡走
• 扫描显示，20,052 个 AI 快速搭建的上线站点中，11.04% 正在泄露数据库凭证

这些不是「小概率事件」。公网上有机器人 7×24 小时专门扫这个，你的站上线几分钟内就会被扫到。

学完这一节，你应该能做到

• 说得清「前端」和「后端」的区别，以及为什么前端藏不住东西
• 认得出 NEXT_PUBLIC_ / VITE_ / PUBLIC_ 这类前缀意味着什么
• 用 grep 在构建产物里自己搜一遍密钥
• 用浏览器 Network 面板自己查一遍
• 万一泄露了，知道第一步是去作废密钥，不是删代码

终极验收：把你的仓库地址交给一个陌生人，他花 10 分钟用 DevTools 翻遍你的站，找不到任何一个 Key。