为每个环境配置独立 API 密钥：分步操作指南

开发、预发布和生产环境可以运行同一份代码，但不应共用同一把 API 密钥。本指南按环境拆分凭据，再把密钥注入、部署检查和轮换纳入发布流程。目标不是增加配置数量，而是让每次调用都有明确归属，让一次测试失误不必牵动全部环境。

§ 第一步：列出环境与调用入口

先盘点应用服务、后台任务、自动化测试和开发者终端。Vana API 的接入文档覆盖 OpenAI SDK、Codex、Claude Code 和 Gemini CLI；检查时，不要只查看应用服务器，也要查看这些工具使用的凭据。([vanaapi.com](https://vanaapi.com/plug-in?locale=en))

• 开发环境：本地调试、功能试验和临时脚本。
• 预发布环境：集成测试、验收和发布演练。
• 生产环境：真实用户请求和正式后台任务。

为每个入口记录环境、负责人、密钥来源和部署方式。暂时无法确认用途的凭据，先查清引用位置，不要直接删除。

§ 第二步：按环境准备独立密钥

如果尚未开始使用，可以先创建一个 Vana API 账户，再分别为三个环境准备独立密钥。用清晰的名称记录用途，例如“订单服务—开发”“订单服务—预发布”“订单服务—生产”。这些是管理标签，不是密钥内容。

不要把同一把密钥复制三次后仅修改名称。检查三个部署配置实际引用的是不同凭据，并记录创建日期与负责人。如果当前账户无法准备多把密钥，先确认可用的隔离方式，不要将共用凭据标记为已完成隔离。

§ 第三步：保持代码一致，分开注入凭据

在应用内部统一配置项名称，例如 VANA_API_KEY，再由不同环境注入各自的值。这里的名称是应用约定，不代表 SDK 会自动识别；初始化客户端时，需要显式读取并传入密钥。工具自带的凭据变量则按其接入要求配置。

本地可使用不提交到版本库的环境文件；预发布和生产优先使用部署平台的密钥存储。提交配置模板时只保留变量名称和说明，不填真实值。若密钥缺失，应让启动或部署检查明确失败，不要自动回退到其他环境的凭据。

§ 第四步：检查访问与部署边界

把生产密钥的读取范围限定在确有需要的服务和人员。持续集成任务按部署目标读取对应凭据，不要让普通测试任务默认获得生产密钥。也不要为了复现问题，直接把生产密钥下载到个人电脑。

分别检查密钥和数据：更换 API 密钥时，不要顺带复制生产数据库连接、用户提示词或业务记录。测试使用经过处理的数据，并单独核对数据库、队列和回调地址是否仍指向正确环境。

§ 第五步：逐个环境验证调用

先验证开发环境，再验证预发布，最后处理生产。每个环境发送一次内容简单、输出长度受控的请求，确认认证和响应正常。迁移凭据期间，尽量保持模型、请求内容与其他参数不变，减少排查变量。

• 核对部署目标与密钥存储条目的对应关系。
• 检查日志只记录环境和内部标签，不打印密钥。
• 如果平台提供按密钥查询用量的能力，再检查调用归属。

成功返回一次响应，只能说明该凭据可用。还应检查是否存在旧环境文件、共享脚本或默认配置继续引用原来的共用密钥。

§ 第六步：迁移完成后撤销旧密钥

不要在替换前直接停用仍被服务使用的共用密钥。先部署新配置，完成验证，再检查定时任务、长驻进程和回滚配置。确认所有依赖都已迁移后，撤销旧密钥，并通过一次受控验证确认它已无法认证。

为后续轮换保留同样的操作顺序。回滚版本可以恢复代码，但不应恢复已经撤销或泄露的凭据；回滚路径也要读取当前有效的环境密钥。

§ 第七步：把隔离检查加入发布清单

每次新增服务或环境时，检查三个问题：凭据是否独立、谁能读取、如何撤销。指定负责人，记录最近一次验证日期，并在人员权限或部署流程变化后重新检查。

如果发现密钥泄露，优先撤销受影响凭据，部署替代值，再排查日志、构建产物和配置文件中的副本。最后核查其他环境是否曾共用该密钥。把环境边界落实到实际凭据，而不只是名称，才算完成这次配置。