密钥泄露之后：判定、轮换与最小爆炸半径
一句话回答
密钥一旦进入客户端、日志或提交历史，藏就不再由你控制。本文把重点放在泄露后的判定分级、先加后减的轮换顺序，以及让下一把密钥不致命的几个前置条件；具体平台的密钥管理能力与撤销时延待核实。
如果只问“怎么把密钥藏好”，答案会很快失效：密钥一旦进入客户端代码、日志或提交历史，是否暴露就不再由你决定。更稳的顺序是承认密钥迟早会泄露，先让它泄露后不致命，再让它能被快速换掉。本文只谈这两件事的工程做法。需要说明：本次没有可核验的联网素材，涉及具体平台（包括 API.PLUS）的密钥管理界面、是否支持多把密钥并存、撤销生效时延，均待核实，不能据本文推断。
判定：先分级，再决定动作#
发现疑似泄露时，先回答四个问题，再决定是“记录观察”还是“立即轮换”：
- 权限范围：只读、可写、可删除，还是能触达计费与他人数据。
- 是否仍然有效：是否已被撤销、是否本就过期。
- 暴露载体：公开仓库、公开构建产物，还是权限受限的内部日志。
- 是否已有不可撤回的副本：fork、镜像、包缓存、他人本地克隆，这些不会因为你删掉源文件而消失。
这里有一条推断而非事实：一把只读且额度极低的密钥，其处理优先级通常低于可写、可转账或可读取他人数据的密钥。这是按影响面排序，不构成对任何平台风险等级的判断。
轮换顺序：先加后减#
直接删掉旧密钥会让所有调用方同时失败。更常见的顺序是：
- 新建一把密钥，权限按实际需要给到最小。
- 部署调用方，使其优先读取新密钥，同时保留旧密钥作为回退。
- 观察一段时间内的调用来源，确认没有仍在用旧密钥的调用方。
- 撤销旧密钥。
- 对仓库历史、构建产物、日志再做一次扫描，确认没有残留。
难处通常在第二步之外：移动端、桌面端和嵌入式设备的分发不由你控制，无法强制所有实例同步更新，双活窗口要按版本分布来定。具体窗口长度取决于你自己的版本数据，本文无法给出通用数值。
| 阶段 | 动作 | 常见失败表现 | 回退方式 |
|---|---|---|---|
| 并存 | 新旧密钥同时有效 | 调用方只改了一半配置 | 回退到旧密钥继续服务 |
| 切换 | 默认使用新密钥 | 部分实例仍读旧配置 | 延长双活窗口 |
| 撤销 | 旧密钥失效 | 长尾调用方报错 | 仅能新建，无法恢复旧密钥 |
让下一把密钥不那么要紧#
- 按用途与环境拆分密钥，测试与生产不共用。
- 默认只读，写权限单独授予。
- 密钥只出现在服务端运行时环境变量中，不进入构建产物与前端包。
- 若平台支持短期凭据，优先使用；是否支持待核实。
- 提交前扫描加历史扫描，两者不能互相替代。
一次轮换演练该回答什么#
与其在事后讨论，不如平时演练一次：从决定轮换到旧密钥失效用了多久？有多少调用方需要同步改配置？谁有权撤销？这三个答案决定了真实泄露时的损失上限。
// 未执行的示例：服务端按“当前/上一把”读取密钥，便于双活切换（Node.js 环境）
const ACTIVE = process.env.API_KEY_CURRENT; // 占位：YOUR_KEY
const PREVIOUS = process.env.API_KEY_PREVIOUS; // 占位：YOUR_KEY
function resolveKey(request) {
// 真实实现应按调用方标识决定使用哪一把，此处仅示意读取路径
return request.headers['x-key-version'] === 'previous' ? PREVIOUS : ACTIVE;
}这段代码只说明“密钥从运行时环境读取、不写死”这一条，未在真实环境执行，也不处理缺失值、日志脱敏与鉴权。
边界#
本文给出的是通用工程顺序，不针对某个平台的具体功能。API.PLUS 的密钥创建、权限粒度、并存数量与撤销生效时间，需以其官方文档与控制台实际行为为准；在这些信息核实之前，不应把本文当作其能力描述。
