API key 泄露了怎么办？第一小时做什么

AI 开发里最贵的一课，往往从一封账单邮件开始：key 被提交进了公开仓库，爬虫抓走新提交的凭据只要几分钟，冒用产生的调用量却要等到账单跳出异常才被看见。泄露不挑人——手滑 commit、前端把 key 打进客户端包、日志里顺手打印，都是高频剧本。真正拉开差距的是第一小时的动作顺序：做对了，损失以小时计；做错了，以天计。这篇按排障篇的惯例给一条固定顺序：吊销、对账、轮换、排查泄露面、补预防，逐件事展开；平时的管理规范见key 管理做法一篇，应急之前先有常态。

第一件事：立即吊销，删文件不等于收回

发现泄露，第一动作是去平台后台把这把 key 作废（revoke 或删除），而不是先去改代码。顺序有讲究：key 一旦可见就按已被抓走对待，删除仓库里的文件、甚至改写提交历史，都收不回已经流出的字符串——爬虫的抓取以分钟计，你的清理以小时计。后台作废是一刀切断，旧 key 立即失效，冒用戛然而止。这一步唯一的取舍是：吊销会让所有还在使用这把 key 的服务当场断掉。这是好事，断掉的首先是冒用者的调用，你自己的服务随后用新 key 接回，中断时间可控。

第二件事：查用量与账单，圈定损失

吊销之后马上对账。打开平台的用量面板，按时间线看这把 key 在暴露窗口期内的调用记录：调用量级、调用模型、接口类型，与自己的业务正常水位对照，异常部分就是冒用证据。窗口期从 key 可能暴露的时间点算起——不确定暴露时刻的，往早了算，宁可多查不要漏查。账单侧同步核对：已产生的费用明细截图留存，涉及争议扣费时这是凭证。账单异常的对账方法与告警设置，账单异常排查一篇有完整展开，异常用量的典型形态（循环调用、批量刷量）也在那篇里。

第三件事：轮换签发，替换所有使用点

吊销切断了旧 key，业务还要继续，轮换紧随其后。生成新 key，替换所有使用点：本地环境变量、部署平台的配置、CI 与 CD 的密钥设置、服务器上的配置文件。使用点的清单要在平时就列好，应急时逐项打勾，漏一处就是一次线上故障。轮换完成后再补一步验证：用新 key 跑一遍核心调用，确认全部链路恢复。管理侧的轮换纪律（周期与触发条件）在 key 管理一篇讲过，应急场景只需要多记一条：新 key 上线后，把它的暴露面重新过一遍，别让新 key 立刻重蹈覆辙。

第四件事：排查泄露面，找到那个口子

查清 key 是从哪漏的，否则换几把都会再漏。常见泄露面按命中率排：一是版本库，提交历史里的老 commit、ignore 规则晚了一步的 .env；二是客户端打包，前端应用或开源客户端把 key 编进发布包，任何人解包都能拿到，这是社区最高频的泄露剧本之一；三是日志与错误上报，key 被打印进日志后随日志收集流走；四是聊天记录与截图，key 被贴进群聊、工单、issue。代码侧的泄露场景与案例，代码泄露一篇有专门整理；账号层面的失陷——邮箱、后台账号被盗——是另一类事故，处理路径见账号盗用一篇。

第五件事：补预防，让同类事故不再发生

应急收尾时把预防机制补上。第一层是扫描钩子：仓库装上 pre-commit 阶段的密钥扫描（gitleaks 一类工具），提交前自动拦住疑似密钥的字符串，CI 里再跑一道全量扫描兜底。第二层是入库白名单：默认不提交，明确放行才入库，比黑名单式的 ignore 稳。第三层是客户端整改：前端与客户端应用永远不该内置 key，需要调模型就走服务端代理转发。第四层是权限与额度：新 key 按最小权限签发、设好额度上限，下次即便再漏，损失也被框住。整套流程想固化成团队资产，可以让 DeepSeek 把应急五步整理成一页卡片，再用腾讯元宝按真实事故复盘的格式出一版演练脚本，半年跑一次桌面推演就够用。

key 泄露应急速查

• 顺序固定：吊销、对账、轮换、查泄露面、补预防
• 先后台作废再清代码，删文件收不回已流出的 key
• 暴露窗口期往早了算，用量面板逐项对照
• 高发泄露面：提交历史、客户端打包、日志、群聊
• gitleaks 一类扫描钩子加 CI 兜底，额度上限是自动刹车

关于 key 泄露的三问三答

• 不确定 key 是什么时候漏的怎么办？窗口期往早了算，把对账范围拉到 key 创建以来的全量记录，多查不亏。
• 吊销后业务中断算事故吗？算可控代价。断掉的是冒用与旧配置的调用，按轮换流程把新 key 替换到位，中断以分钟计。
• 私有仓库里的 key 也要作废吗？要。私有只是门槛不是隔离，协作扩容、误转公开都会让历史里的 key 复活，按已泄露处理最稳。