API Key 安全管理：别让一把密钥拖垮整个业务
密钥泄露途径 · 环境变量 · 服务端代理 · 轮换 · 泄露应急清单
核心结论：大模型 API Key 等同于你账户的「印钞权」。一把泄露的密钥能在几小时内刷光额度甚至导致封号。安全不是可选项，是上线前的及格线。
一、密钥最常见的泄露途径
- 硬编码进前端 JS 或移动端，被任何人扒取；
- 含密钥的
.env误提交到公开/私有代码仓库； - CI/CD、服务器日志把密钥打印出来；
- 通过来路不明的第三方代理转发，密钥经手他人；
- 群聊、工单里明文发送密钥。
二、正确的调用架构
浏览器 / App
│ （只连你自己的后端，不持有 Key）
▼
你的后端服务
│ （环境变量读取 API Key，统一限流/审计/缓存）
▼
大模型官方 API核心原则：密钥永远不出服务端。前端需要智能能力时，调用你自己的接口，由后端代理模型请求。
三、落地防护清单
- 隔离：开发、测试、生产用不同密钥，权限最小化。
- 存储：用环境变量或密钥管理服务，
.env必须进.gitignore。 - 传输：全程 HTTPS，禁止明文传密钥。
- 轮换：定期更换密钥，员工变动立即回收。
- 监控：对异常调用量与陌生 IP 设告警。
应急怀疑泄露时：立刻作废旧密钥 → 换新 → 排查来源 → 核对调用记录 → 视情况联系服务商。动作越快，损失越小。
四、常见问题
API Key 为什么不能写进前端代码？
前端代码对用户完全可见，任何人都可扒出密钥直接调用并刷爆你的额度，甚至触发封号。密钥只应存在于受你控制的服务端或环境变量中。
把 Key 放环境变量就安全了吗？
比硬编码进代码好很多，但仍要注意：不要把含密钥的 .env 提交到代码仓库；生产环境用密钥管理服务而非明文文件；CI/CD 日志也可能意外打印密钥。
前端要调用模型，正确架构是什么？
前端只连你自己的后端，由后端持有 Key 转发请求（即「自有后端代理」）。这样密钥不出服务端，还能统一做限流、审计与缓存。
发现密钥可能泄露了怎么办？
立即在平台作废该密钥并生成新的；排查泄露源（仓库、日志、前端、第三方代理）；review 近期调用记录看有无异常消耗；必要时联系服务商。
多人协作怎么管密钥？
用密钥管理平台或云厂商的 Secret 服务，按最小权限分配，禁止在群聊/邮件里明文传密钥，离职即回收。
用第三方中转服务方便，能用吗？
风险在于密钥经手他人。若必须使用，选可审计、有资质的服务商，且密钥单独隔离、限额，绝不复用生产主密钥。
开源项目要演示调用，密钥怎么办？
用占位符与读取环境变量的示例，明确文档提示「请勿提交真实密钥」，并提供限额的演示密钥或本地自托管方案。