API 密钥不是集成中的技术细节，而是一种支付工具。谁掌握这串令牌，谁就能不经额外确认花掉你的余额——系统核验的是这个值本身，而不是操作它的人。开发者接入计费、号码或代理服务时拿到的这段字符看似普通变量，实际上等同于能直接动用账户资金的卡。下面梳理它最常从哪里泄露、该放哪里、如何按任务和人员拆分权限，以及泄露后该怎么办。
密钥等于余额的访问权
API 令牌证明的不是身份，而是花费的权利。系统只核验这串值，并不追问是谁发出的请求。一旦字符串落入他人之手，对 API 而言这仍是一次合法请求：购买号码、租用代理、从余额中扣款——都会以账户的正常操作被处理。仅凭一次请求无法区分是被盗用还是正常使用，唯一有效的防线是不让密钥落入他人之手，而不是事后分辨请求是否被冒用。
密钥不该出现在哪里
密钥总从同样几个渠道泄露。代码仓库——一段「为测试随手」提交的字符串会永远留在版本历史里：后续删除文件并不会抹去更早快照中的值，一旦仓库被公开或误分享，这个发现几分钟内就会变成他人对余额的访问权。容器镜像——写死在构建文件里或作为构建参数传入的这段值，会沉淀为镜像的一层，随镜像流转进它抵达的每个仓库，其中不乏权限比生产环境宽松的测试环境。
页面客户端代码——浏览器接收并执行的一切，任何访问者都能通过开发者工具读到；一个没有自建后端中转、直接面向服务器的值，就以明文形式暴露在那里。请求的地址栏——作为路径或查询参数传递的这段值，会随网址一起被复制到它出现的每个地方：服务器与代理日志、浏览器历史、跳转时的来源页头，有时诊断信息里的错误文本也会把完整网址回显出来。它正确的位置是请求头，而不是路径或参数字符串。
密钥该放在哪里
基本原则很简单：它不应以明文存在于会被提交进仓库的代码或配置里。运行进程应从服务器或编排层设定的环境变量中读取该值，而不是从源码旁边的文件读取。配置示例文件可带着空白或明显假的占位值提交，真正持有凭证的文件永远不进仓库——它被列在忽略清单里。对于凭证不止一个、且需定期更换的团队，光靠环境变量还不够，需要独立的密钥管理系统按需下发值、记录调用日志，并能不改动应用代码就撤销访问。
按任务和人员分开密钥
一个凭证用到底，是最常见也最昂贵的简化做法。如果生产服务器、测试脚本和第三方集成共用同一个值，泄露后就必须整体吊销——正常服务会和真正泄露源头的脆弱测试环境一起停摆。至少应按两条线拆分访问权限：按任务（生产、持续集成、本地开发、合作方对接），以及按拥有访问权的人或团队。这样吊销一个凭证，应对的是具体一起事件，而不是让整个计费系统停摆。额外好处是，某个凭证的调用日志能直接看出哪个任务在消耗余额，异常支出能立刻被定位。
轮换——计划内与应急
计划内轮换指按日程签发新凭证并吊销旧值，而不是等出事之后才做。不中断服务的顺序是：先签发新值，暂不吊销旧值；把新值部署进服务配置并确认请求正常通过；确认无误后再吊销旧值。短时间内两个值同时生效是正常状态，基础设施本身支持这种过渡。
一旦怀疑泄露，顺序正好相反：先吊销，后排查。立即吊销可疑密钥，哪怕还没有百分之百确认——签发新值期间的短暂中断，代价远低于别人拿你余额消费的损失。随后调出可能泄露那段时间的交易记录，核对是否与系统实际操作一致。如果它曾和其他凭证放在一起——比如同一台服务器的密码、代理 API之类相邻服务的令牌——一并更换：泄露渠道很少只波及一个值。换新凭证后如何不撞上请求上限，见API 限流与速率限制一文。
常见问题
密钥已经出现在公开仓库里，该怎么办？
立即吊销，哪怕包含它的提交已被下一次提交删除——版本历史保留文件的每个版本，删除不会抹去更早快照里的值。签发新凭证，更新配置，确认正常工作后再切换流量；把旧值标记为已吊销，而不只是不再使用。
能不能签发一个只对应单一操作、而非整个 API 的密钥？
如果服务支持限定作用范围的密钥——比如只能只读余额、无扣款权限——就把这类凭证用在不需要完整权限的任务上。这样的限定即便落入他人之手，损失也有限。
如果一直没有泄露，密钥多久换一次比较合适？
更换频率取决于有多少人和系统持有访问权：范围越广，安全间隔应越短。合理基准是工作密钥至少每季度轮换一次，任何持有人离开时也应立即轮换。
密钥的请求头传递格式，以及吊销和限流时的响应代码，详见OTP API 文档。