API Key 管理
让每把 API Key 都能回答三个问题：谁在使用、用于什么环境、出现风险时能否单独停用。
创建和管理是两个阶段。 创建时保存完整密钥；管理时持续维护名称、状态、有效期和额度。列表中的前缀或摘要通常只能用于识别，不能替代完整 Key 发起请求。
先建立拆分原则
一个实用命名方式是 应用-环境-用途，例如 web-prod-chat 或 ops-staging-image。名称不需要很长，但必须能在异常发生时被快速认出来。
一把 Key 的完整生命周期
创建并安全保存
在控制台生成 Key 后立即保存完整密钥。不要把它写入前端代码、截图、群聊或 Git 仓库；服务端接入应通过环境变量或可信的密钥管理工具读取。
设置用途、有效期与额度
名称说明归属，过期时间限制生命周期，单 Key 额度限制影响范围。测试、第三方客户端和临时脚本通常应该比生产服务更严格。
用最小请求完成验证
创建后先发送一条最小请求，确认完整 Key、Base URL 和模型名称能一起工作。验证流程见 5 分钟完成第一次请求。
持续观察使用情况
上线后回到 用量与账单，确认这把 Key 的消耗与预期业务量一致。如果平台支持按 Key 查看来源，应优先用这一维度定位异常。
轮换后再停用旧 Key
先创建替代 Key，更新调用方并验证新 Key，再禁用旧 Key。确认没有请求继续使用旧 Key 后，才考虑删除记录。
常见管理动作怎么选
怀疑泄露时的处理顺序
- 在控制台禁用可疑 Key，先阻断继续调用
- 为受影响应用创建用途明确的替代 Key
- 更新服务端配置并验证最小请求
- 查看异常时间段的用量、任务和调用来源
- 排查仓库、日志、截图或第三方工具中是否留有完整密钥
- 确认旧 Key 不再产生请求后再删除
不要把“删除旧 Key”当作第一步。先禁用可以快速止损，同时保留识别记录，便于核对哪些调用仍在使用它。
定期巡检清单
- 是否存在无法确认负责人或用途的 Key
- 开发、测试与生产是否仍然共用凭证
- 是否有已经过期、长期不用或状态异常的 Key
- 单 Key 额度是否仍符合当前业务规模
- 第三方工具和临时脚本的 Key 是否已经回收
- 最近用量是否能与已知应用和环境对应