Image-2 API Key 泄漏后怎么处理？先吊销，再轮换服务端配置

API Key 一旦出现在前端代码、公开日志、截图或第三方工单里，就不要再把“先删掉那一行”当作处理完成。只要旧 Key 仍有效，拿到它的人仍可以调用接口。正确顺序是：先吊销，再创建、轮换、复核。

泄漏响应只走四步

图注：先让旧 Key 失效，再把新 Key 安全送进服务端。

第一步，在Image-2 开放平台找到对应 Key 并吊销。不要等新版本部署完成才吊销；止损优先于无中断。如果业务不能停，也应在明确的短窗口内完成双 Key 切换，而不是让旧 Key 长期共存。

第二步创建新 Key。只在受控的服务端环境接收和保存，避免复制到聊天、截图或前端构建变量。Key 的显示、传递和存储都应按凭据处理。

第三步更新服务端配置并重启或热加载真实调用进程。确认所有实例、定时任务和队列消费者都拿到新 Key；只改一台机器会造成一部分请求仍使用旧 Key。

第四步做两次复核：新 Key 能正常读取能力或提交受控测试；旧 Key 调用应被拒绝。日志里只记录 Key 的内部标识或脱敏尾部，不回显完整值。

轮换后还要找泄漏源

检查前端 bundle、CI 日志、错误追踪、工单附件和代码历史。删除当前文件不能抹掉已经发布的历史；如果凭据曾进入 Git，仍以“已泄漏”处理，不要依赖重写历史替代吊销。

API 文档明确要求服务端调用。普通网页用户要生图，应使用Image-2 页面，不需要接触开放平台 Key。

最小完成标准不是“新 Key 能用”，而是四项同时成立：旧 Key 已吊销、新 Key 仅在服务端、所有调用方已轮换、日志没有再次泄露。