API密钥怎么轮换？从依赖清单到旧凭据失效验证
一把 API 密钥可能同时被网站进程、定时任务、备份程序和发布流水线使用。只修改正在运行的网站，常常会留下隔天才报错的任务。轮换开始前，先明确凭据能访问哪些资源、被哪些组件使用，以及平台是否允许短时间并存两把密钥。
例行轮换和泄漏处置不能用同一节奏
例行轮换可以先准备新凭据，分批迁移调用方，再在观察后撤销旧凭据。若已经确认密钥被公开，旧凭据继续有效的时间本身就是风险，应优先按事件处置安排撤销或限制，必要时接受可控的服务中断。不能因为还没找齐所有脚本，就让高权限泄漏凭据无限期存在。
OWASP 密钥管理指南将创建、轮换、撤销和到期视为一个生命周期。以下步骤是面向小型服务器应用的操作安排，不代表某个平台具有双密钥、热更新或自动撤销功能。
先建立使用位置清单
按资源与组件记录凭据编号、权限、负责人、配置来源和更新方式。清单可以写“订单通知服务通过受控环境文件读取通知平台令牌”，但不要复制令牌值。除主进程外，还要检查队列消费者、计划任务、灾备环境、旧镜像、运维电脑和持续集成变量。
对调用频率低的任务，记录下一次自然运行时间，并判断能否安全执行一次测试。若备份程序每周运行，轮换后观察十分钟显然不足以证明所有使用方都已迁移。可以通过明确的试运行与日志检查缩短等待，而不是盲目扩大观察窗口。
给新密钥合适的权限和有效期
创建新密钥时重新核对实际需求，不要默认继承旧密钥的全部管理员权限。测试环境与生产环境、读操作与写操作，尽量用能区分职责的身份或权限范围。平台支持到期时间时，也应把续期责任和告警一起安排好。
更新配置前保存可恢复的旧配置版本，但不要把旧密钥重新散落到普通备份、日志或工单中。变更记录保留密钥标识、配置版本和时间即可。密钥是否写入进程环境、文件或密钥服务，取决于应用能力；环境变量本身并不等于加密存储。
切换后验证真实调用路径
先在可控实例上更新凭据并按应用要求重新加载或重启。验证一个权限允许的真实业务动作，同时检查认证失败、权限不足、限流与网络错误，避免把不同问题都归结为“密钥无效”。读接口成功不能证明写接口权限也足够，因此测试范围要与生产用途一致。
确认前台请求、后台任务和备用节点都已经使用新配置，再进入撤销阶段。如果要回退，应先判断旧凭据是否仍可信；已泄漏的旧凭据不应重新启用来恢复业务，而应建立新的受限凭据或调整应用配置。
撤销之后，还要验证旧密钥确实失效
通过平台的正式管理入口撤销旧凭据，记录操作时间与执行人。在允许且受控的测试中确认旧密钥不再能完成原有调用，同时新密钥仍然正常。随后观察错误率和低频任务结果，检查是否还有遗漏的使用方。
如果泄漏来自代码仓库，仅删除当前文件或追加忽略规则不会让已经公开的凭据自动失效。GitHub 的敏感数据处理说明明确将撤销或轮换放在前面；历史清理应另行评估协作影响，不能当作撤销的替代。
结束轮换时更新清单，关闭不再使用的密钥，写明实际验证过的调用方与尚需跟进的低频任务。下次轮换能否更快完成，取决于这次是否把隐藏依赖留下了清楚记录，而不是只记一句“密码已改”。