团队共用一把 Key 的风险：换人、对账与最小权限速查

小团队图省事，往往一个 Key 全组用：谁在用、花了多少、人走了怎么办，全说不清。这篇不讲概念，直接给可落地的拆法——哪些场景该拆子 Key、限额卡在哪一层、多久轮换一次，再配一张责任分配表和一份交接清单。买之前按这个走一遍，后面少吵几次架。

小团队图省事，往往一个 Key 全组用：谁在用、花了多少、人走了怎么办，全说不清。这篇不讲概念，直接给可落地的拆法——哪些场景该拆子 Key、限额卡在哪一层、多久轮换一次，再配一张责任分配表和一份交接清单。买之前按这个走一遍，后面少吵几次架。

先把结论放前面：共用一把 Key 不是绝对不行，而是要看「有没有分账需求」和「会不会出现在别人电脑上」。这两条只要中了一条，就老老实实拆，别等出事再补。

共用一把 Key 最容易出的三类事

第一类换人，第二类对账，第三类失控。这三类事故的共同点是：平时看不出问题，出事的那天全组一起救火，而且往往赶上晚上或者周末。

• 换人：同事离职或换项目，Key 还在对方本地配置里，你既不敢停又不敢留，只能连夜全组改配置
• 对账：账单只有一个总额，没人分得清是哪个项目、哪个客户端烧的，预算复盘时只能靠猜
• 失控：某台机器脚本跑飞，或者 Key 被贴到公开仓库，额度在几个小时内被抽干，没有限额挡不住

需要说明不适用的情况：如果全组就你一个人用，Key 也只在自己机器上，那下面这套流程基本是负担，做好本地保存和备份就够了。

子 Key 怎么拆、限额卡在哪一层

拆分维度有三个：按人分、按项目分、按环境分（生产和测试分开）。人少的时候优先按项目拆，不要按人拆，否则一个人离职要动好几把 Key，交接成本反而更高。

限额优先卡在中转站或平台侧的单 Key 额度上，再叠加客户端侧的并发与重试设置。只在客户端限制等于没有限制，因为改一改配置就绕过去了。具体支持到什么粒度，到站内对应站点页面核对当时的说明。

• 每个子 Key 命名带上用途和负责人缩写，后台一眼看出是谁的
• 命名规范写进团队文档，新人不按规范建就直接打回
• 平台不支持子 Key 时，按人拆成多把独立 Key，用一张表格登记
• 限额值按「这个项目最多能烧多少」反推，而不是按「大概够用」拍

轮换节奏与交接清单

轮换不用搞得太神秘，触发条件写死三条就够：有人离开、Key 出现在不该出现的地方、站点侧提示异常登录或用掉用量突增。没触发条件时按固定周期轮换，间隔结合自己用量和人员流动频率定，不用照抄别人的数字。

1. 列归属把现有 Key 逐个列出来，写清归属人、用途、绑定的站点和分组。
2. 对用量把后台用量和登记表对一遍，有差异的先查是不是有人偷偷加了客户端。
3. 降额观察旧 Key 先降额再观察几天，确认没有漏掉的调用方，再彻底停用。
4. 归档记录把这次轮换的时间、原因、执行人记进表格，方便下次回溯。

交接清单至少包含五项：Key 归属与用途、绑定的站点与分组、当前余额与限额、最近一次对账结果、下一步由谁接手。少一项，接手的人就得回头问一遍。

旧 Key 直接删，最容易把线上服务打断；先降额，再观察，最后停用。

团队采购责任分配表

责任分不清是共用 Key 的根源之一。下面这张表建议直接抄进团队文档，四个人以下的小团队可以一人兼两职，但「管 Key 的」和「用 Key 的」尽量别是同一个人，否则限额形同虚设。

对账差异大的时候，先查是不是有人偷偷加了客户端，再查是不是有脚本在重试。这两条能解释大部分异常，剩下的才需要怀疑泄露。具体怎么对，到站内对账相关页面看操作步骤。

采购前顺手确认的几件事

很多麻烦在买之前就能问清楚。选站点的时候别只看单价，先看它能不能帮你把这套管理做完。

• 是否支持子 Key、能否单独限额、能否看到每个 Key 的用量明细
• 后台能不能按 Key 导出用量，导出字段够不够对账
• 充值金额按项目分开放，别一次全压在同一个站点
• 把客服回答和条款截图存档，尤其是封号、退款、Key 共享的口径

不支持子 Key 和单独限额的站点，后面的管理全靠人工表格硬撑，人一多就会失控。选站点时可先到站内站点目录筛一遍支持情况，再看价格。