API Key 轮换，怎么避免新旧配置混在一起？

给模型接入换 Key，常见做法是在控制台新建一个、把环境变量改掉、立刻删旧的。小项目看起来只改一行，实际可能有多个进程、后台任务和旧标签页仍在用旧值。如果没有先盘点使用位置，删旧 Key 后出现的 401 很难与模型权限、端点故障区分。

先列出使用该 Key 的客户端清单：应用服务、定时任务、本地 CLI、测试环境、构建流水线。表中只写配置变量名、部署位置、负责人和最后一次成功调用时间，不写密钥原文。再确认新旧 Key 归属同一账号或具备同样的模型权限；否则“换 Key”同时改变了授权条件，测试结果没有可比性。

轮换可以分四步进行。第一步创建新 Key，给它单独的标识和最小权限，放进受控配置系统。第二步在非生产环境做最小请求，再做实际使用的流式或工具任务。第三步逐个服务切换配置，记录切换时间与进程版本，并用请求标识确认新请求确实走新 Key。第四步观察一个事先设定的窗口，确认没有旧进程继续调用，再停用旧 Key。若出现异常，回退的是服务配置版本，不是在聊天里临时复制旧密钥。

以“两台应用实例加一个夜间任务”为例，发布顺序可以写成一张检查单：先更新夜间任务所用的受控配置，但等它下一次真实运行或用等效的测试任务验证；再更新第一台实例，确认最小请求和目标模型任务通过；最后更新第二台实例。观察窗口要覆盖夜间任务的运行周期，不能只看白天十分钟。这里的实例数量是演练条件，不是某个平台的实际架构。

运行时日志最好只保留一个本地 Key 代号，例如 key_generation=2026-11-b，不要打印 Key 前后几位当作“方便定位”。HTTP 401 应记录发生时间、服务版本、配置代号、模型 ID 和请求路径；原始 Authorization 头不能进日志。多实例服务要逐台确认部署与健康，不能看到一台通过就删旧 Key。

发布流程还需明确“谁能新建 Key、谁能更改配置、谁能停用旧 Key”。一个人运营的小服务可以是同一个人执行，但动作仍要留下时间和检查结果，避免过几周已经忘了哪次轮换影响了某个定时脚本。若密钥疑似泄露，处理顺序可能需要更快地停用旧值；那是安全事件流程，不能照普通轮换的观察窗口慢慢等待。文中的顺序适用于计划内轮换，不代替泄露应急预案。

停用旧 Key 后做最后一次核对：查看旧代号在观察窗口内是否还有请求、核对新代号是否覆盖目标模型、确认失败告警没有持续增长。若业务使用流式响应，还要观察完整结束而不是只看首字到达。把这些检查写进轮换工单，下次再换 Key 时就能沿用同一张表，而不是重新靠记忆操作。

将 NexoToken 接入自建应用时，可以照此清单轮换平台签发给当前账号的 Key。目录里某型号可见不代表新 Key 已获得同样的权限，切换前后应使用同一条脱敏任务核对。本文给的是轮换顺序和记录方法，不声称任何平台已经在某次故障中出现上述问题。没有可公开的真实运行数据，就保留“待验证”的栏位。