API Key 怎么保存和使用？先确认密钥属于哪个服务 - AIPlan

API Key 不是万能密码，它只在签发它的那个服务里有效。官方平台签发的 key 只能请求官方地址，中转站签发的 key 只能请求该中转站地址，两者的字头、权限和账单各管一段。所以保存之前先回答一个问题：这把 key 属于哪家、对应哪个项目、从哪个账户扣费。答不上来就先别往代码里写。 三个东西必须同时对上 很多认证失败不是 key 写错了，是三样东西没对上：请求地址、模型名、key 的签发方。 元素 例子 错了会怎样 Base URL https://api.openai.com/v1 或某个中转域名 401 或 404，日志里看不出原因 模型名 gpt-6.1-sol、gpt-6-luna 404 model not found，或悄悄降级到别的模型 API Key sk- 开头的平台 key 或中转站自建 key 401 invalid_api_key 最常见的情况是：软件默认填了官方地址，你粘的是中转站的 key。表面上都是 sk- 开头，实际是两套认证体系。排查时先看请求打到了哪个域名，再看 key 的签发方，不要反复重试同一组配置。 环境变量，别再写死进代码 官方文档给的变量名是 OPENAI_API_KEY。Python 里这样读： import os api_key = os.environ["OPENAI_API_KEY"] if not api_key: raise SystemExit("OPENAI_API_KEY 未设置") # 变量只传给客户端构造函数，不要 print，不要写进日志。 Node.js 对应 process.env.OPENAI_API_KEY。用中转站时通常还要一起设 OPENAI_BASE_URL，两个变量成对出现，缺一个就会打到错误的服务上。 为什么要用环境变量而不是常量：代码会进 git、会被打包、会被截图分享，环境变量不会跟着走。这条规则的价值在泄露发生时体现：key 在环境变量里，你只要换掉值；key 写在代码里，你得改代码、重新提交、清理历史。 .env 与 .gitignore 必须成对检查 .env 文件本身不危险，危险的是它被提交了。 先确认 .gitignore 里有一行 .env，再确认历史提交里没有。检查历史用 git log -p -- .env | head -50，有输出就说明曾经提交过。仅从当前文件删掉不够，历史里那份副本还在，克隆仓库的人依然能读到。 仓库里应该放的是 .env.example，只写变量名和占位值： OPENAI_API_KEY=sk-replace-me OPENAI_BASE_URL=https://api.openai.com/v1 这条和代码托管平台无关，公开仓库和私有仓库都一样，因为私有仓库也会加协作者、会 fork、会因为权限配置失误变成公开。 前端代码里绝对不能有 key 浏览器里运行的 JavaScript 是明文交付的。用户在开发者工具的 Network 面板里能看到所有请求，包括 Authorization 头。 如果你的网页需要调用模型，正确结构是：浏览器请求你自己的后端，后端持有 key 并转发。中间那一层还承担了三件事：按用户限流、记录用量、在 key 泄露时只换一处。 把 key 写进前端还有第二层风险：key 一旦被爬走，账单是你的，用量是别人的。官方按 token 计费，Sol 输出 $10.00/百万 token，Astra 输出 $50.00/百万 token，跑一整夜就是几百美元。 按项目拆 key，不要一把用到底 一把 key 打天下，会带来两个具体麻烦：账单分不清哪项任务花的钱，泄露时只能全部停掉。 按用途拆开之后： • 测试用的 key 单独一把，限额设低，随时可删。 • 生产用的 key 单独一把，只放在生产环境。 • 一次性脚本用的 key，跑完就删。 拆开的前提是平台支持多项目。官方平台的 key 归属于某个项目，用量按项目统计，这一点决定了拆分的粒度。所有 key 都在同一个项目里，账单还是混在一起。 限流和预算提醒不是一回事 这是最容易被误解的一处。设置一个消费上限，不等于超过就自动停机。 官方的用量页可以看到按天、按模型的花费曲线；项目级的预算提醒会发邮件，但邮件到达时用量已经产生了。真正能拦住超额的是硬性支出上限（如果账户支持）或你自己的限流逻辑。 自建限流的做法很简单：在调用前记一次计数，按天或按小时重置，超过阈值直接返回错误。这段逻辑放在你的后端，不要指望平台替你做。 日志里要脱敏，不是删干净 排查问题的日志需要状态码、请求 ID、模型名、耗时、token 数。这些都可以留。 不能留的是完整的 Authorization 头、请求体里的用户隐私、以及 key 的完整值。 一个可用的写法：只记录 key 的前 8 位和后 4 位，中间用星号替代。既确认用了哪把 key，又不会在日志泄露时把 key 一起交出去。 请求 ID 值得单独留。它是向平台提问的唯一凭据，客服能凭它查到这次请求的实际状态。没有请求 ID，你只能说“我这边报错了”。 key 泄露后的处理顺序 发现 key 出现在公开仓库、日志或截图里，按这个顺序做，不要跳步。 第一步，撤销。 在签发平台删除这把 key。删除立即生效，比生成新 key 更重要——先止血。 第二步，生成新 key 并替换。 新 key 只放在环境变量或密钥管理服务里，不要顺手粘进聊天窗口做“测试”。 第三步，查用量。 看泄露期间有没有异常调用。官方平台可以按项目和日期筛，重点看深夜时段和非你所在地区的调用。 第四步，清历史。 从仓库历史里移除，必要时重写历史并通知协作者重新克隆。这一步排在后面，因为它耗时且不影响止血。 关于“先撤销还是先排查”，答案固定是先撤销。排查可以在撤销之后做，因为撤销不会销毁历史用量记录。 常见误判：报错不一定是 key 的问题 几种错误长得像 key 失效，实际不是。 • insufficient_quota：key 有效，账户余额不足。订阅 Plus 不解决这个，因为 ChatGPT 和 API 是两套账单。 • 429 Too Many Requests：限流，不是认证失败。看响应头里的重试时间。 • model_not_found：key 没权限用这个模型，或者项目没有开通该模型。 • invalid_api_key：这一条才是 key 本身的问题，可能是复制时带了空格或换行。 第二种情况有专门的说明，见订阅已开通但程序仍报余额不足。把账单边界搞清楚，能省掉一半无效排查。 动手前的一张检查表 写完代码、上线之前，逐条对一遍： • .gitignore 里有 .env，git log -p -- .env 无输出。 • 代码里没有任何以 sk- 开头的字符串字面量。 • 前端产物里搜 sk-，结果为空。 • 日志里没有完整 Authorization 头。 • key 按用途拆开，测试和生产不共用。 • 有按天或按小时的调用上限，不依赖邮件提醒。 • 请求 ID 记录在日志里，能对上平台后台。 这七条里任何一条没做到，都属于“还没准备好上线”。 如果你同时也在用 Codex 这类工具，它有自己的认证路径，key 和订阅登录是两条线，可以对照Codex 工具在仓库里的安全边界一起看。 最后补一句价格参考：官方 Plus 20 美元/月（约 133.80 元人民币，按 1 美元 ≈ 6.69 元折算），Pro 200 美元/月（约 1,338.00 元）；而 API 是按 token 单独计费，Sol 输入 $2.00/百万、输出 $10.00/百万。两条账不能互相抵扣，这一点在保存 key 之前就该弄清楚。本文口径为 2026 年 10 月 18 日核对，官方调整定价或权限模型后需要重新确认。 参考资料资料核对日期：2026-10-17 • Text generation • Managing billing for ChatGPT and the API platform | OpenAI Help Center 延伸阅读• ChatGPT 订阅和 API 有什么区别？先看你从哪里使用 • Codex 操作项目时，权限、密钥和命令范围怎样管理？ • CDK 充值时怎样保护账号？分清订单信息与登录凭据 • 关注实时信息，Grok 和 ChatGPT 应该怎样比较？