第 6 章：API Key 与泄露响应 — 密钥泄露后先止血¶

📋 本章概览¶

API Key 是“代表你调用服务的凭证”。它可能产生费用、访问数据或调用模型，所以不能写进源码、截图、Issue、聊天记录或公开仓库。环境变量能减少误提交，但不是绝对保险。

把 API Key 当成会花钱的钥匙¶

API Key 与普通密码相似，但它经常被程序、脚本和 CI 自动使用；一旦泄露，别人可能在你没有察觉的情况下调用服务，产生费用或消耗配额。它不应该出现在源代码、截图、终端历史、错误日志、公开仓库或聊天记录里。即使密钥看起来“只是测试用的”，也要按真实凭证处理。

发现泄露时最重要的是顺序。先让旧密钥失效，阻止继续使用；再检查调用记录、账单和可能传播的地方；最后生成新密钥并改进配置。仅仅把文件删除或把最后一次提交改掉，不能保证旧值没有留在历史、缓存或日志中。

6.1 认识密钥出现在哪里¶

你可能在服务商后台创建 Key，在 Agent 或程序配置中使用它，在环境变量中保存它。看到类似 sk- 的长字符串、Token 或 Secret 时，不要复制到公开地方；本教程的示例只使用占位符，例如 YOUR_API_KEY。

6.2 安全配置的基本原则¶

从服务商官方文档进入创建页面；只创建需要的 Key；如果可以设置权限和额度，使用最小范围和预算提醒；本地配置文件加入忽略规则；提交 Git 前检查差异和日志。

不要把 Key 写在命令行历史、屏幕截图、教学录屏、Markdown 示例或环境变量打印结果中。

6.3 发现泄露后的顺序¶

1. 立即在服务商后台撤销或禁用旧 Key。
2. 创建新 Key 并更新本地配置。
3. 检查调用记录、费用、权限和异常 IP。
4. 从公开页面和 Git 历史清理泄露内容。
5. 检查其他服务是否复用了同一凭证。
6. 必要时联系服务商，保留时间线和证据。

清理 Git 文件不能让已经被别人看到的 Key 自动失效；撤销旧 Key 才是第一步。

6.4 不含密钥的检查¶

在提交前查看 git diff，搜索 key、token、secret 和服务商常见前缀；看到真实值时停止提交并立即撤销。不要为了确认“能不能用”而把密钥打印到终端或发给别人。

✅ 验证步骤¶

写一张不含真实密钥的应急卡，包含服务商后台入口、撤销位置、账单检查位置、权限检查位置和联系渠道；模拟一个占位符泄露，不要使用真实 Key。

❌ 常见情况¶

📝 本章总结¶

• Key 是凭证，不是普通配置文字。
• 泄露响应第一步是撤销，之后才是清理和调查。
• 任何教程、日志和截图都只能使用占位符。

🎉 结课任务¶

完成一页个人安全清单：主邮箱入口、2FA 状态、恢复路径、共享链接检查、公共设备退出步骤和 API Key 泄露应急卡。完成后可以进入搜索与信息判断。