API 密钥安全最佳实践
API Key 的风险在于它通常同时代表身份、权限和预算。中转站场景下，密钥还会经过第三方链路，因此更需要把“密钥放在哪里、谁能使用、什么时候轮换、如何发现异常”提前设计清楚。
不要把密钥提交到代码仓库
Section titled “不要把密钥提交到代码仓库”API Key 一旦进入 Git 历史记录，就很难确认它是否已经被复制、缓存或上传到外部服务。团队应至少做到：
.env、密钥文件和本地配置进入.gitignore。- Pull Request 中检查是否出现明文密钥。
- CI 日志不打印完整环境变量。
- 发现泄露后立即吊销旧密钥，而不是只删除代码里的文本。
.env.env.local*.keysecrets/优先使用环境变量
Section titled “优先使用环境变量”环境变量能让应用在不同环境读取不同密钥，而不需要把敏感信息写进源代码。
export OPENAI_API_KEY="YOUR_API_KEY"export OPENAI_BASE_URL="https://example-relay.com/v1"开发、测试和生产环境应使用不同密钥。部署平台、CI、容器编排和服务器运维系统也应使用各自的密钥注入机制，而不是把密钥写入镜像或配置模板。
最小权限原则
Section titled “最小权限原则”如果服务端支持权限范围、额度上限或模型范围限制，应为不同项目创建不同密钥。
| 场景 | 建议 |
|---|---|
| 个人实验 | 使用低额度密钥，避免绑定主账户高额度 |
| 团队开发 | 每个项目单独密钥，便于定位异常消耗 |
| 生产服务 | 限定模型范围、调用额度和来源环境 |
| 临时测试 | 设置短周期密钥，测试后立即删除 |
多人协作时，不要共用个人主密钥处理团队任务。共享主密钥会让权限、账单和责任边界都变得不可追踪。
定期轮换与异常检查
Section titled “定期轮换与异常检查”长期不轮换的密钥会扩大泄露后的排查难度。建议为关键项目建立固定节奏：
- 创建新密钥。
- 在测试环境验证新密钥。
- 更新生产环境配置。
- 观察调用和错误率。
- 删除旧密钥。
发现异常消耗时，先冻结或删除可疑密钥，再排查日志与部署环境。不要等到确认根因后才止损。
中转站选择时的安全信号
Section titled “中转站选择时的安全信号”选择中转站时，优先看这些信号：
- 域名稳定，站点说明清晰。
- 支持基础账单查询和密钥管理。
- 明确说明接口兼容范围和模型列表。
- 不要求上传其他平台的原始密钥。
- 能看到价格更新时间、公告和联系方式。
RelayRadar 的边界
Section titled “RelayRadar 的边界”RelayRadar 的接入模板只展示 Base URL 和占位符，不要求提交密钥。后续如果提供更多交互工具，也应保持密钥只在用户本地或浏览器临时上下文中处理，不进入 RelayRadar 服务端。