在大模型应用刚兴起的时候，我也一度被“纯前端直连模型 API”这种方案吸引过：不需要后端、不需要部署服务，前端拿到 key 直接请求模型接口，几行代码就能跑起来，Demo 效果立竿见影。但当这种方案真正进入工程讨论，甚至被尝试放进测试环境后，问题很快暴露出来，而且几乎都绕不开“安全”这个核心主题。
一、API Key 泄露几乎是必然事件
从工程角度看，只要 API Key 出现在前端环境，就意味着它已经不再是秘密。无论是写在代码里、放在构建产物中，还是通过环境变量注入，最终都会被打包进浏览器可访问的资源。即使做了混淆、压缩，熟悉前端调试的人依然可以通过 Network 面板、Source Map、甚至直接拦截请求轻松拿到 key。
很多人会寄希望于“低频使用”“内部项目”或“没人会注意”，但现实往往相反。一旦 key 泄露，风险并不会体现在功能异常上，而是体现在账单和配额消耗上，而且通常是滞后发现。
二、配额滥用不是假设，而是常态
API Key 一旦暴露，就等于给了任何人“无限试错”的机会。你无法控制第三方如何使用这个 key：
- 被脚本刷调用
- 被嵌入到其他站点
- 被当作“免费模型接口”传播
从系统角度看，这类问题几乎无法通过前端手段解决。前端无法限制调用频率、无法区分真实用户和恶意请求，更无法基于业务逻辑做精细化控制。一旦出现异常消耗，往往只能通过整体吊销 key 来止损，代价是服务中断。
三、所谓“前端代理”的常见误区
有些方案看起来像是折中方案：在前端和模型 API 之间加一层“轻量代理”，但实际上只是把风险换了个位置。如果这个代理只是简单转发请求、不做鉴权、不校验来源、不限制调用频率，那么它本质上仍然是一个“公开接口”，只是从浏览器调用变成了 HTTP 调用。
真正有意义的后端代理，至少需要承担以下职责：
- API Key 的安全托管
- 基于用户或业务的权限控制
- 请求限流与异常监控
- 日志与审计能力
如果这些能力缺失，那么“加一层代理”更多只是心理安慰，而不是工程上的安全设计。
四、从 Demo 思维到工程思维的转变
纯前端直连模型 API 在 Demo 阶段并非完全不可接受，它的价值在于快速验证想法。但一旦系统进入可持续运行阶段，模型调用就已经成为后端资源的一部分，需要被纳入整体系统的安全、成本和稳定性管理中。此时，把关键调用放在后端，反而能让前端变得更简单、职责更清晰。
在实验阶段，我用过 GPT Proto 提供的统一接口来快速对比不同模型的调用方式，但在最终方案中，依然选择将核心模型调用收敛到后端完成，这也是目前更稳妥、也更符合工程实践的做法。