OpenAI API Key 怎么安全保存和使用？

更新于 2026-10-26 · gpt.boats

简答：OpenAI API Key 应只在服务端使用：本地开发用环境变量或未提交的 .env，前端请求自己的后端，CI/CD 使用加密 Secret，生产环境再升级到密钥管理服务。真实 Key 一旦出现在仓库、构建产物、截图或日志中，应立即轮换并检查用量。

定义：OpenAI API Key 是用于验证 API 请求身份的秘密凭据，应由服务端从环境变量、Secret 或密钥管理服务加载，而不是暴露给浏览器、移动应用或公开代码。

先看四场景决策表：Key 应该放在哪里

本站是第三方 AI API 接入指南，不是 OpenAI 官方站。OpenAI 官方建议把 API Key 当作秘密凭据，不要共享或放进浏览器、移动应用和公开代码，而应由服务端从环境变量或密钥管理服务加载。可参考 OpenAI API 参考中的认证说明和 API Key 安全最佳实践。

按使用场景选择 OpenAI API Key 保存方式

场景	优先方式	边界	上线前检查
个人本地开发	环境变量或本机未提交的 .env	不写进源码，不上传仓库	检查 .gitignore、Git 状态和本机备份
前端、移动端、浏览器扩展	前端请求自有后端，由后端调用 API	不要把真实 Key 打包进客户端	搜索构建产物、源码和请求配置
团队协作	成员独立凭据或项目级 Key	不要在群聊、工单和文档中共享个人 Key	按项目、成员和环境追踪用量
CI/CD	平台加密 Secret 或环境 Secret	不要写进 workflow 文件或日志	限制注入任务、环境和分支范围
生产部署	密钥管理服务；支持时使用短期身份凭据	不要打包进镜像或前端资源	设置轮换、权限、用量和支出控制

这张表把官方能力与通用工程建议分开：环境变量、项目隔离、项目 Key 的权限与用量管理属于平台配置能力；.gitignore、Docker 注入、日志脱敏和后端代理属于通用工程实践，不能理解为平台会自动替你完成。

本地开发：环境变量和 .env 怎么配置

优先使用环境变量

OpenAI 的开发者快速入门使用 OPENAI_API_KEY 作为环境变量名，官方 SDK 可以从系统环境读取它。macOS 或 Linux 当前终端可以执行：

export OPENAI_API_KEY='你的真实Key'

Windows PowerShell 当前会话可以执行：

$env:OPENAI_API_KEY = '你的真实Key'

如果希望在 Windows 后续终端中继续使用，可按官方示例设置持久环境变量：

setx OPENAI_API_KEY "你的真实Key"

验证时不要直接回显完整密钥。可以只判断变量是否存在：

if [ -n "$OPENAI_API_KEY" ]; then echo "OPENAI_API_KEY is set"; else echo "OPENAI_API_KEY is missing"; fi

PowerShell 可使用：

if ($env:OPENAI_API_KEY) { "OPENAI_API_KEY is set" } else { "OPENAI_API_KEY is missing" }

环境变量配置方式和 SDK 自动读取方式可查看 OpenAI Developer quickstart。

使用 .env 文件时的最低防护

本地项目可以使用 .env，但它只是文件保存方式，不是自动加密。建议将真实凭据放在本机未提交的 .env 中，并把以下规则加入 .gitignore：

.env .env.* !.env.example

.env.example 只保留变量名：

OPENAI_API_KEY=

提交前执行：

git status git diff --cached git ls-files | grep -E '(^|/)(\.env|.*\.env\.)'

如果只是在本机未提交的 .env 中保存 Key，重点检查文件权限、云盘或备份同步、误上传和日志泄露；如果真实 Key 出现在公开仓库、构建产物、前端资源、截图或第三方日志中，则按已泄露处理。

Node.js 和 Python：不把 Key 写进代码的最小调用

Node.js 示例

先安装官方 SDK：

npm install openai

将下面内容保存为服务端脚本。示例只从进程环境读取 Key，模型名请替换为当前项目可用的模型：

import OpenAI from "openai"; const client = new OpenAI(); const response = await client.responses.create({ model: "你的模型名", input: "只返回一句测试文本", }); console.log(response.output_text);

Python 示例

先安装官方 SDK：

pip install openai

Python 示例修正为可运行形式：

from openai import OpenAI client = OpenAI() response = client.responses.create( model="你的模型名", input="只返回一句测试文本", ) print(response.output_text)

官方快速入门展示了 Node.js 和 Python 从环境变量读取凭据并调用 Responses API 的基本结构，可对照 Developer quickstart。生产代码还应避免把完整请求头、环境变量、异常对象、提示词、用户输入或响应内容无差别写入日志。

前端为什么不能直接放 Key：正确架构是后端代理

只要真实 Key 出现在浏览器 JavaScript、移动应用、桌面客户端、浏览器扩展或公开下载包中，使用者就可能通过开发者工具、资源文件或反编译获取它。OpenAI 官方安全指南明确建议不要在客户端环境部署 Key，请求应先经过你自己的后端。可查看 API Key 安全最佳实践。

前端只请求你的后端接口，例如 /api/ai。
后端验证用户身份、请求大小、频率和允许使用的模型或功能。
后端从环境变量或密钥管理服务加载 OPENAI_API_KEY。
后端调用 API，只向前端返回必要结果。
日志只记录必要的请求 ID、状态和耗时，并对提示词、用户输入、响应内容和业务标识做脱敏、最小化记录和访问控制。

请求 ID可用于故障排查，但它不等于可以无条件记录全部请求内容。OpenAI API 参考建议在生产环境记录请求 ID，同时应用仍需按照自己的数据保护要求控制日志内容，相关说明见 API Overview。

ChatGPT Plus、Pro 等 ChatGPT 订阅与 API 平台不是同一套凭据和计费入口。需要调用 API 时，应在 API 平台单独创建和管理 Key，具体账户权限和计费以官方页面为准，参考 ChatGPT 与 API 平台的计费说明。

团队、CI/CD 与生产：什么时候升级保存方式

团队协作：按成员、项目和环境拆分

不要共享某位成员的个人 Key。OpenAI 建议每位团队成员使用独立 Key，并可按成员、产品、功能或项目拆分凭据，以便进行权限控制和用量追踪。项目可以用于组织成员访问、模型使用、速率、支出和 API Key 管理；具体可用权限以当前控制台显示为准，参考 Managing projects in the API platform。

开发、测试、预发布和生产建议使用不同项目或不同 Key。若当前账户提供项目 Key 的过期时间、权限范围、轮换或访问限制，应按最小权限配置；并非所有账户、组织角色或工作负载都能看到相同选项。

GitHub Actions：使用加密 Secret

GitHub Actions 支持仓库、组织和环境级 Secret。环境 Secret 可以结合审批规则限制生产任务；Secret 需要在 workflow 中显式注入，而不是写进代码。参考 GitHub Actions Secrets。

name: api-check on: [push] jobs: call-api: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm ci && npm run api-check env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

GitHub 会对部分 Secret 做日志脱敏，但官方也提醒自动脱敏不是绝对安全边界；不要主动打印 Secret，也不要把它拼进命令行参数。来自 fork 的工作流、Dependabot 工作流和环境审批还可能有不同的 Secret 注入规则，应按 Using secrets in GitHub Actions 核对。

生产环境：密钥管理服务与短期凭据

当应用进入多人协作、自动部署或生产阶段，建议将 Key 放入云平台或企业密钥管理服务，并让运行时按权限读取，而不是把 Secret 写进 Dockerfile、镜像层、仓库或部署脚本。OpenAI 也列出密钥管理服务和工作负载身份联合等生产方案；能否使用短期令牌取决于当前工作负载和平台配置，参考 API Overview 与 Production best practices。

判断是否需要升级的简单标准是：只在一台本地电脑上试验，可先用环境变量或未提交的 .env；一旦需要团队共享、自动部署、生产运行、审计访问或定期轮换，就应使用项目隔离、CI/CD Secret 或密钥管理服务，并同步设置用量、支出和访问控制。

泄露后的五步处理：先撤销，再排查和替换

只要真实 Key 出现在公开仓库、Git 历史、构建产物、前端资源、截图、聊天记录、CI 日志或第三方日志中，就应按已泄露处理。仅删除当前文件不能让旧提交中的凭据失效。

立即删除或轮换：在 API Key 管理页面删除受影响的 Key，或先创建替代 Key，确认应用切换成功后再撤销旧 Key。API 参考说明，撤销通常会在几秒内生效，但其他认证相关更新可能需要更长时间传播，因此不要只等待传播。
检查用量与支出：查看 Usage、项目支出、请求时间和异常模式，保留必要的排查信息。
替换全部运行环境：更新本地 .env、CI/CD Secret、容器变量、云平台 Secret 和部署配置。
清理 Git 历史与日志：从相关提交、分支、构建产物和日志中移除凭据，并通知协作者重新同步安全版本。
收紧后续控制：启用可用的 Key 过期、轮换、项目隔离、权限、用量监控、支出提醒、硬性支出限制或 IP 允许列表。

OpenAI 文档明确说明，支出提醒只负责通知，硬性支出限制可以在达到已追踪支出后停止受影响请求，但执行并非瞬时，记录支出可能略高于配置值；IP 允许列表则可限制 API 请求来源。是否适合启用要结合固定出口、部署拓扑和业务容错，参考账户安全说明、用量与支出限制排查和 IP allowlisting for OpenAI API。

如果泄露发生在 GitHub，先撤销或轮换真实 Key，再清理提交和分支中的历史内容。不要只依赖 GitHub 日志脱敏，因为复杂变形、拼接或外部进程输出可能绕过预期的显示效果。

发布前安全自查清单

真实 Key 是否只存在于服务端、环境变量、CI/CD Secret 或密钥管理服务？
浏览器、移动端、浏览器扩展、公开下载包和前端构建产物中是否没有真实 Key？
.env 是否已加入 .gitignore，并用 git status、git diff --cached 和 Git 历史搜索确认没有误提交？
团队是否使用成员独立凭据或项目级 Key，而不是共享个人 Key？
开发、测试、预发布和生产是否分离？
CI/CD 是否使用加密 Secret，并限制注入的任务、环境和分支？
日志是否避免记录 Authorization、完整环境变量、提示词、用户输入和响应内容？
是否设置了可用的过期、轮换、权限、用量监控、支出提醒、硬性限制或 IP 控制？
如果怀疑泄露，是否知道从哪里删除或轮换 Key、检查用量并替换全部部署环境？

如果真实 Key 只存在于本机未提交的 .env，重点是文件权限、备份同步和误上传检查；如果它已进入公开资源、仓库历史或第三方日志，则不要继续使用原 Key。

常见问题

ChatGPT Plus 或 Pro 订阅包含 OpenAI API Key 吗？

不包含。ChatGPT 产品订阅与 API 平台是分开的产品和计费系统。需要调用 API 时，应在 API 平台单独创建和管理 API Key，具体权限和计费以官方账户页面为准。

可以把 OpenAI API Key 放在前端 JavaScript 里吗？

不应这样部署。浏览器代码、移动应用和扩展都可能被查看、调试或反编译。正确做法是前端请求自己的后端，再由后端从环境变量或密钥管理服务读取 Key 调用 API。

.env 加入 .gitignore 后就安全了吗？

不能保证。它只能降低误提交概率。应继续检查 git status、git diff --cached、Git 历史、备份同步、构建产物和 CI 日志；真实 Key 一旦进入公开资源或第三方日志，应按泄露处理。

OpenAI API Key 泄露后第一步做什么？

第一步是立即删除或轮换受影响的 Key。随后检查 API 用量和支出，替换本地、CI/CD、容器和云平台中的配置，再清理 Git 历史并收紧权限与支出控制。

团队成员可以共用一个 API Key 吗？

不建议。共享 Key 会降低成员、项目和环境的用量追踪能力，也会扩大泄露影响范围。应使用成员独立凭据或项目级 Key，并按环境分开管理。

如何确认 Key 没有被打印到日志？

搜索代码、CI/CD 配置、容器启动脚本和日志规则，重点检查 Authorization、环境变量转储、异常对象、提示词、用户输入和响应内容。验证配置时只输出是否存在或脱敏结果。

什么时候应该从 .env 升级到 Secret Manager？

单机试验通常可以先用环境变量或未提交的 .env；当项目需要团队协作、自动部署、生产运行、审计访问或定期轮换时，应升级到 CI/CD Secret、项目隔离或密钥管理服务。