很多人对 API Key 的态度是「先跑通再说」：粘进代码里、发到群里、塞进 Git 提交——能跑就行。直到某天账单突然翻了几倍，才发现钥匙早就不在自己手里了。这篇不讲恐慌，只讲三件能立刻做的事：认出泄露的常见路径、把轮换变成例行动作、把每把钥匙的权限收紧到刚好够用。
Key 是怎么漏出去的
最高频的一条路是版本控制。把 Key 写死在源码里，第一次提交就被记录进了历史——哪怕你在下一个提交里删掉，旧提交里那串字符依然躺在那儿，谁克隆下来都能翻到。第二条路是复制粘贴：贴进群聊、写进工单、发到截图里，然后被转发、被存档、被搜索引擎收录。
还有一类更隐蔽：前端代码。把 Key 写进浏览器里运行的页面，等于把它印在传单上发给每个访问者。浏览器端的请求谁都能在开发者工具里看到，无论你把它藏得多深，混淆也只是提高了阅读门槛，不是加密。
判断一句话：这把 Key 会不会离开你的服务器？会，那就等于已经公开了。
轮换：把「换钥匙」变成例行动作
轮换的意思是定期作废旧 Key、启用新 Key。它解决的不是「已经泄露」的问题，而是「还不知道有没有泄露」的问题——只要换得够勤，任何一次泄露的影响窗口都被压缩在有限天数内。建议的做法是给自己定一个周期，比如每 90 天一次，写进日历，到点就换，不靠记性。
换的时候用「先建后删」的顺序：先在控制台创建新 Key，把它更新到所有调用方，确认流量正常，再作废旧 Key。反过来先删后建，会让所有调用方在中间那段时间全部失败。如果怀疑已经泄露，顺序也一样，只是要立刻执行——先把新 Key 铺上去，再马上作废旧的，别为了排查原因让旧钥匙继续有效。
最小权限：一把钥匙只开一扇门
很多人图省事，全项目共用一把最高权限的 Key。这样做的代价是：任何一处泄露都等于全盘失守，而且出事之后你分不清是哪个环节漏的。更稳的做法是按用途拆开——线上服务一把、本地开发一把、临时测试一把，各自独立。
拆分之后还有一层：能用额度控制的，就别只靠权限。本站在控制台可以给每个 Key 单独设置额度上限，把测试用 Key 的额度压到刚好够跑完验证就行。这样即便它漏了，损失也是有天花板的，而不是一个未知数。至于 Key 本身，永远放在环境变量或服务器的密钥文件里，别进代码库；本地调试用的 Key 和线上用的也不要混。
常见问题
Key 已经提交到 Git 了怎么办？
第一件事是立刻作废它，而不是先改代码——只要它还有效，清理历史都来不及。作废之后再去处理代码：把 Key 挪进环境变量，确认新提交不再包含它。至于历史记录，改写提交历史或者直接重建仓库都可以，但要注意这两件事都只在你作废之后才有意义。
换了 Key，为什么调用开始报错？
常见原因有三个：调用方还缓存着旧 Key，更新后没重启服务；某处硬编码的 Key 被漏掉，没跟着一起换；或者新 Key 的额度、权限与旧的不一致，请求被拦在网关那一层。排查时先确认报错来自哪一端，再去看是「钥匙不对」还是「钥匙权限不够」，这两类问题的处理方式完全不同。
多个人一起用，要不要共用一把 Key？
不建议。共用意味着无法区分用量、无法单独停用、任何一人泄露都要全员重配。更省事的做法是按人或者按用途各发一把，出问题时点对点处理，几分钟就能收口，而不是停下来开会讨论该停谁。