把密钥藏进前端环境变量，并不等于保护密钥。只要它参与浏览器里的请求，就可能出现在构建产物、网络面板或运行时内存中。这一轮上线前检查，只完成一个目标：让浏览器能使用模型，却始终拿不到上游密钥。
第一步：查清密钥是否已经进入浏览器
先检查前端请求、静态配置、构建目录和源码映射文件，再搜索代码仓库与提交历史。不要只找完整密钥，也要查找鉴权请求头的组装位置。压缩、混淆、编码和拆分字符串都不能让浏览器里的秘密真正保密。
如果密钥已经公开，先撤销，再替换。删除代码无法收回别人已经复制的凭据；同时检查近期用量和异常调用。
第二步：画出只有后端接触密钥的链路
把调用路径改成“浏览器请求自家后端，后端携带密钥请求模型服务，后端返回结果”。前端只提交业务需要的输入，不再直接调用上游。没有常驻服务器时，也可以使用受控的云函数，但必须在服务端执行。
如果需要统一接入多家模型，可以注册 SwiftRelay，将其密钥保存在后端，由后端统一发起调用。中转服务简化的是上游接入，不会替你完成应用用户的身份验证。
第三步：把密钥注入服务端运行环境
开发环境使用不提交到仓库的本地配置，生产环境使用部署平台的密钥管理功能。确认变量仅供服务端读取，不会被构建工具替换进前端文件，也不会通过页面配置返回给浏览器。
- 开发与生产使用不同密钥，避免测试操作影响正式业务。
- 配置文件加入版本控制忽略规则，并检查是否曾被提交。
- 启动时检查密钥是否存在，但不要把密钥值写进日志。
第四步：让后端验证用户并限定调用能力
后端入口必须检查有效登录态，并确认当前用户有权使用这项功能。需要注意，跨域限制不是身份校验，攻击者仍可绕过浏览器直接请求接口。使用会话凭据时，还应按认证方式补齐跨站请求防护。
由后端固定上游地址，维护允许使用的模型列表，并限制输入长度和输出额度。不要接受前端传来的任意目标地址、鉴权请求头或无限制参数，否则中转接口可能变成公开代理。
第五步：给每个用户设置用量边界
仅仅藏好密钥，不能阻止已登录用户滥用服务。按用户限制请求频率、并发数和可消费额度；在发起上游请求前检查额度，并为处理中请求预留预算，避免并发绕过检查。
请求完成后记录实际词元用量并结算。对超限请求明确拒绝；对于断线和重试，也要设计取消与去重策略，避免重复生成带来额外费用。
第六步：清理响应和日志里的秘密
后端只返回页面需要的内容，不要原样转发上游响应头、异常对象或调试信息。日志保留请求标识、状态和必要用量即可，对鉴权信息与敏感输入进行脱敏。
如果使用流式输出，同样要过滤错误消息，并处理客户端断开连接。浏览器关闭页面，并不代表上游生成一定已经停止。
第七步：用一次验收确认密钥没有回流
部署后打开浏览器网络面板，确认页面只请求自家后端，响应中没有上游密钥。再检查发布产物，并分别测试未登录、额度耗尽和非法模型请求是否被拒绝。
最后演练一次密钥轮换：注入新密钥、验证服务正常、撤销旧密钥。验收标准不是“源码里搜不到”，而是浏览器从未获得密钥，后端也不会替未经授权的人消费额度。