在前端项目中安全调用大模型 API 的实践，我是怎么做的？

前言：这些坑我都踩过
这篇文章算是我在项目里不断踩坑之后的一点经验总结。现在前端接入大模型 API 已经越来越常见，但真正落地的时候，你会发现各种安全细节、架构问题、调用习惯，都比想象中复杂。尤其是前端这种“天生透明”的环境，一点点疏忽就可能把密钥、接口、甚至你的业务逻辑都暴露出去。所以这篇文章不讲大道理，主要分享一些我在实际开发中试过、踩过、后来觉得“早知道这样就好了”的做法。

1.千万别把密钥放前端
这是我见过最多人掉坑的地方。前端调用大模型 API 最忌讳的就是把密钥写在代码里，因为无论你怎么混淆，最终都能被扒出来。正确做法就是——永远通过后端转发。前端只传用户输入，后端再负责真正的 API 请求。
我一开始嫌麻烦想偷懒，后来密钥被人抓走疯狂调用，那次真是付费付得心痛。之后就彻底死心了：所有敏感操作都放后端，省事又省钱。

2.后端要替前端“把关”
既然前端只能传干净数据，那后端就得负责过滤掉各种危险参数。比如：限制最大 token 数；限制调用频率

3.前端不能随便换模型名
不允许传奇怪的 prompt（有些人会想办法绕过限制）。这些限制非常必要，不只是安全问题，也是成本问题。没有限制的话，一个按钮被用户狂点几十次，你就能看到额度像水龙头一样哗哗往外流。

4.前端永远只访问自己的 API，别暴露模型供应商
我现在习惯把前端的所有 AI 请求都指向自己的接口，比如 /api/ai/chat。
为什么？因为只要你直接暴露真实模型接口：切换供应商时前端所有代码都得动，用户能顺藤摸瓜找到真实接口，也就更容易被模拟攻击。而有了自己的代理后端，哪怕你今天用某家、明天换另一家，前端完全不用改一行代码，这种灵活性在项目越来越复杂时特别有用。

5.前端发给后端的内容要“瘦身”
用户的输入往往不干净，有时甚至会带隐私信息。我的习惯是：前端只传必要部分，尽量不要发送整个文档。去掉 HTML 标签、空格、奇怪符号，需要拆分就拆分，不一次性塞给模型。这样做的好处不只是安全，还能降低失败率。大模型有时对无关内容很敏感，干净的输入效果往往更稳定。

6.Prompt 不要全部在前端拼
这一点我起初没意识到，后来才发现——前端暴露的 prompt 模板，就是把你的逻辑、套路、核心提示工程全告诉别人了。
更稳妥的做法是：前端传参数，后端按模板组装完整 prompt。这样你在后端改模板也不影响前端，而且 prompt 真的没必要让用户或攻击者看到。

7.加一点“行为限制”，会让系统稳很多
前端可以做一些简单的限流，比如按钮点击后加一个几秒冷却、防止用户疯狂点。
虽然不是硬安全措施，但能减少很多无意义的重复请求。尤其是当你的模型 API 不便宜时，这种简单限制能省不少钱。

写在最后
前端调用大模型 API 看起来很简单，但真正安全、稳定地落地，需要注意的点远比想象中多。从不暴露密钥，到合理拆分数据，再到控制 prompt 逻辑、隐藏真实接口、限制调用频率，这些都不是“理论”，都是我在项目里反复验证过的经验。如果你的项目需要接入不同供应商的模型（比如 grok、kling 之类），一般也会统一走后端接口，有些团队会直接用类似 GPT Proto 这种能够汇集多家 AI 模型的 API 方式来省掉重复集成的工作，但怎么选都行，只要安全放第一位就好。