OpenAI API Key 安全怎么做？从本地开发到生产的完整清单
简答：OpenAI API Key 不应放在浏览器、移动 App、前端代码或 Git 仓库中。更稳妥的做法是让前端调用自有后端，由后端从环境变量或密钥管理服务读取 Key，再请求 API；同时为开发、测试、生产分项目和密钥，设置过期、监控、消费提醒，并在泄露时立即撤销、检查用量和替换部署变量。
定义：OpenAI API Key 是用于认证 API 请求的敏感凭证，安全管理的核心是避免客户端暴露、限制访问范围、可监控使用情况，并建立轮换和撤销流程。
先看结论：OpenAI API Key 应该放在哪里？
本站是第三方 AI API 接入指南站，不是 OpenAI 官方站。最安全的基本架构是：浏览器或移动 App → 你的后端服务 → OpenAI API。前端只拿到你自己的登录会话或业务接口凭证，不直接持有 OpenAI API Key；后端再从环境变量或密钥管理服务读取 Key，并通过服务端请求调用 API。OpenAI 官方明确建议不要把 Key 部署在浏览器或移动 App 中，而应经由自己的后端转发请求。查看 OpenAI API Key 安全最佳实践
| 位置 | 建议 | 原因与处理方式 |
|---|---|---|
| 浏览器 JavaScript | 不要放 | 用户可以查看打包文件、开发者工具和网络请求，应改为调用自有后端。 |
| 移动 App | 不要放 | 客户端包可能被提取或逆向，Key 不应随应用发布。 |
| Git 仓库 | 不要提交 | 即使仓库是私有的，也可能因权限变更或泄露暴露凭证。 |
| 本地环境变量 | 适合开发 | 使用 OPENAI_API_KEY，并让环境文件进入 Git 忽略列表。 |
| Secret Manager | 适合生产 | 由部署环境按权限读取，避免把明文密钥写入代码和镜像。 |
OpenAI API Reference 将 API Key 作为 API 认证方式的一部分；生产实践文档也建议使用环境变量或密钥管理服务，而不是把密钥硬编码到代码中。查看 OpenAI API Reference 查看 OpenAI 生产实践文档
本地开发：用环境变量保存 OPENAI_API_KEY
本地开发时，先把 Key 放到当前操作系统的环境变量中，代码只读取变量名，不直接保存密钥内容。OpenAI 帮助中心示例使用 OPENAI_API_KEY 作为变量名，并建议通过环境变量避免把 Key 写入代码。查看环境变量配置说明
- macOS 或 Linux：在当前终端执行
export OPENAI_API_KEY='替换为你的Key'。如果需要长期使用，再按你的 Shell 配置文件管理，但不要把真实 Key 粘贴进公开文档。 - Windows PowerShell：当前会话可执行
$env:OPENAI_API_KEY = '替换为你的Key'。设置持久环境变量时，注意只在自己的用户环境中保存。 - Python：代码中读取
os.environ['OPENAI_API_KEY']，不要写成os.environ['OPENAI_API_KEY'] = '真实密钥'。 - 提交前检查：将
.env、本地配置文件、导出的调试日志加入.gitignore，并搜索代码中的sk-等疑似凭证片段。
如果使用 .env 文件，示例可以是 OPENAI_API_KEY=替换为你的Key，但这个文件只应由本地运行环境或部署平台读取，不能提交到仓库。GitHub 官方也建议不要把未加密的凭证推送到仓库，即使仓库是私有的；可以使用 Actions Secret 或其他密钥管理服务。查看 GitHub 凭证安全指南
一个最小的 Python 读取示例是：import os; key = os.environ.get('OPENAI_API_KEY'); assert key, 'OPENAI_API_KEY 未设置'。这段代码只验证变量是否存在，不会把真实 Key 输出到终端。
前端、后端与日志：最容易忽略的泄露位置
判断 Key 是否安全，不能只看源代码。还要检查前端打包文件、浏览器网络请求、错误堆栈、服务器日志、CI/CD 输出和容器环境变量是否被意外打印。只要 Key 出现在浏览器可见内容或公开构建产物中，就应按泄露风险处理，并立即执行撤销与替换流程。
- 前端构建：不要把
OPENAI_API_KEY注入前端构建变量，也不要在浏览器请求头中直接发送 OpenAI 的 Bearer 凭证。 - 网络请求：浏览器只能请求你的业务后端，例如
/api/chat；由后端添加认证头并调用模型服务。 - 错误处理：不要把请求头、完整环境变量或第三方响应原文直接返回给用户。
- 日志系统：记录请求时间、业务用户 ID、响应状态和内部请求 ID 即可，避免记录 Authorization 头、完整请求体中的敏感内容和环境变量。
- CI/CD：使用平台提供的加密 Secret，避免把 Key 写在工作流文件、命令行参数或构建日志中。
GitHub 官方建议将凭证视为密码，限制访问者和权限，并使用 Secret Scanning 发现已经推送的令牌或密钥。发现凭证出现在仓库后，不能只删除当前文件，因为历史提交、分支、构建产物或日志仍可能保留副本；应先撤销旧 Key，再清理暴露位置。查看 GitHub 的凭证存储与修复建议
开发、测试、生产：不要长期共用一把 Key
个人开发者至少应区分本地开发和线上生产；团队项目则应进一步区分开发、测试、预发布和生产。这样做的目的不是让配置更复杂，而是让某个环境的泄露或误操作不会直接影响全部服务。OpenAI 生产实践文档建议为 staging 和 production 创建不同项目，并可按项目设置访问、速率和支出限制。查看项目隔离与生产配置说明
| 阶段 | 最低配置 | 重点检查 |
|---|---|---|
| 个人本地开发 | 环境变量、Git 忽略、定期检查 | 终端历史、调试输出、误提交文件。 |
| 团队测试 | 独立项目、独立 Key、成员独立凭证 | 不要把个人 Key 复制给团队成员。 |
| 生产环境 | Secret Manager、项目权限、消费提醒、硬性支出上限 | 部署变量、日志、轮换、异常用量。 |
| 支持的工作负载 | 评估短期身份令牌或工作负载身份联合 | 先按官方文档确认适用范围和权限配置。 |
OpenAI 官方建议团队成员使用各自独立的 API Key，不要共享同一个 Key；同时可以为项目 Key 设置过期时间并建立轮换流程。对于支持的工作负载，官方还提供以可信身份换取短期访问令牌的工作负载身份联合方案，是否适合你的部署环境需要单独核对文档。查看独立密钥、过期时间与身份联合建议
轮换、撤销和用量监控怎么安排？
密钥轮换不是“出事后才做”，而应成为部署流程的一部分。推荐使用“新 Key 先上线、验证成功后撤销旧 Key”的顺序，避免先撤销旧 Key 导致生产服务立即中断。OpenAI 官方建议在旧 Key 到期前创建替代 Key，更新应用并确认替代 Key 工作正常后，再撤销旧 Key。查看官方轮换流程
- 在管理页面创建新的项目 Key，并记录用途、环境和负责人。
- 把新 Key 写入 Secret Manager 或部署平台的加密变量，不要改代码硬编码。
- 重新部署或重启服务，执行一条最小请求确认认证和模型调用正常。
- 观察错误率、请求量和消费变化，确认流量已经切换到新 Key。
- 撤销旧 Key，并在仓库、CI/CD、日志和服务器中搜索旧凭证残留。
- 把轮换日期、负责人和下次检查时间写入团队运维记录。
生产环境还应设置消费提醒，并根据业务承受能力评估硬性支出上限。官方文档说明，硬性支出上限会在追踪到的支出达到上限后停止受影响的 API 流量，因此启用前要先确认它对业务可用性的影响。查看消费提醒与硬性支出上限说明
如果 OpenAI API Key 泄露，按这个顺序处理
假如你发现 Key 出现在 GitHub、前端文件、截图、聊天记录、日志或错误页面中，不要等待确认是否已经被使用。应先把它视为已暴露凭证，按以下顺序缩短风险窗口：
- 立即撤销：在 API Key 管理页面删除或撤销泄露的 Key。官方说明指出，被删除的 Key 不能继续使用，依赖它的应用会停止工作，因此要准备好替代 Key。
- 检查用量：查看异常时间段的请求量、模型使用和消费记录，保存必要的时间线与请求标识。
- 创建替代 Key：为对应项目创建新 Key，写入部署平台或 Secret Manager。
- 替换并验证：重新部署服务，使用最小请求检查认证、业务功能和错误率。
- 清理暴露面：审计 Git 历史、分支、构建产物、CI/CD 变量、服务器日志和前端资源。
- 通知相关人员：如果 Key 被团队共享、出现在客户环境或可能影响账单，应通知负责人并记录处置结果。
如果只是忘记保存完整 Key，官方建议重新创建，而不是尝试恢复旧值；完整密钥只在创建时显示。查看创建、删除和重新创建 Key 的说明
发布前的 OpenAI API Key 安全自查表
- 架构：浏览器和移动 App 不保存 OpenAI API Key，所有模型请求经过自有后端。
- 代码：仓库中没有真实 Key，示例文件只保留变量名或占位符。
- 配置：本地使用环境变量，生产使用 Secret Manager 或部署平台的加密变量。
- 权限：团队成员不共享 Key；不同环境、项目和服务尽量使用独立凭证。
- 生命周期：Key 有过期、轮换和撤销流程，且明确负责人。
- 监控：已配置用量查看、消费提醒、异常请求排查和必要的支出限制。
- 日志：不输出 Authorization 头、环境变量、完整密钥或未经处理的敏感请求内容。
- 应急：团队知道泄露后的先后顺序：撤销、查用量、替换、验证、清理、记录。
如果只能先做三件事：第一，把 Key 从前端移到后端；第二，把代码中的明文 Key 改为环境变量或密钥管理服务；第三，为开发和生产使用不同项目与 Key，并设置用量监控。这三步能覆盖大多数基础配置问题。
常见问题
OpenAI API Key 可以放在前端 JavaScript 里吗？
不建议。浏览器中的代码、开发者工具和网络请求都可能被用户查看，OpenAI 官方建议将请求路由到自有后端，由后端安全保存并使用 API Key。
把 OpenAI API Key 放进 .env 就一定安全吗？
不一定。.env 只是降低误提交风险的一种方式，仍需加入 .gitignore，并确认它没有被前端构建、日志、容器镜像或 CI/CD 输出暴露。生产环境应优先使用密钥管理服务或部署平台的加密变量。
OpenAI API Key 不小心提交到 GitHub 后怎么办？
先立即撤销或删除泄露的 Key，再检查用量和异常请求；随后创建替代 Key、更新部署变量，并清理仓库历史、分支、构建产物和日志中的残留。只删除当前文件不等于旧 Key 已失效。
团队成员可以共用一把 OpenAI API Key 吗？
不建议。官方建议每位团队成员使用独立 Key，并按项目和环境隔离。独立凭证更容易追踪使用、撤销单个成员权限并执行轮换。
生产环境需要设置 API Key 过期时间吗？
建议设置。官方建议为项目 Key 设置过期时间并建立定期轮换流程；上线替代 Key 并确认正常后，再撤销旧 Key。具体可用的过期与治理选项以管理页面和官方文档为准。