技术 · 熟练
谁能建 key、多久过期，团队里说得清吗？
设置管的是以后，存量得你自己翻出来
平台方最近把两件原本靠口头约定的事做成了设置：一是新 key 可以带过期时间、并且管理员能要求「每个新建的 key 都在期限内过期」；二是「谁可以建 key」本身有三档 —— 只允许服务账号 key、只允许用户自有的项目 key、或禁止新建任何 key。这两条一落地，团队里就多了一件必须拍板的事：你们选哪一档、上限设多久。麻烦的地方在于 —— 设置只管「以后」，既有 key 不受影响，而存量里那些「从来没设过过期」的长寿 key 要自己列出来轮换。这一页的顺序是：先定档位 → 再定寿命 → 再把存量翻出来 → 最后让每条 key 都能回答「谁在用、什么时候到期、在哪儿吊销」。
方法 · 一图看懂
1
先定「谁能建 key」这一档 — 三选一：只允许服务账号 key（最严，人不能直接建）· 只允许用户自有的项目 key（各自管各自的）· 禁止新建（冻结，只留存量）。⛔ 不定就等于默认「谁都能建」，这是团队里最容易失控的一格
2
给新 key 设最长寿命 — 在组织或项目上设一个上限，让「永不过期」不再是被动的默认值。判据很简单：这个 key 被泄漏之后，最坏情况下它能被用多久 —— 上限就是这个时间
3
把存量长寿 key 单独列出来轮换 — ⚠️ 设置只管新建，既有 key 一律不受影响；所以真正的工作量在这一步：翻出「从没设过过期」的那些，按用途分组，排一个轮换顺序
4
让每条 key 都能回答三个问题 — 谁在用（哪个服务 / 哪个脚本 / 哪个人）· 什么时候到期 · 在哪儿吊销。答不上来的 key 先当没有 —— 它现在是一条没人负责的通行证
原理 · 为什么有效
密钥治理难，不在技术，在「声明」与「生效」之间没有自动对账 —— 你在控制台里选了「禁止新建」，这件事对已经存在的 key 一点影响都没有；你把寿命上限设成 90 天，也不会有人告诉你手上有 12 条三年前建的、永不过期的 key。所以这一页的第一步不是「怎么配」，而是「怎么证明配上了」：档位要能说出谁受影响，寿命要能对上「泄漏后被用多久」这个判断，存量要有一份可核的清单。
另一条同样关键：平台方对企业自发布的能力默认是「先给能力、再补治理」 —— 三档治理与寿命上限都是后来才加的 ⇒ 说明早期建的 key 天然缺这两样。⇒ 存量不是例外，是常态。
适用场景
适用：一个团队 / 组织里多人在用同一家的 API、且已经出现「不知道谁建的 key」「离职的人手上的 key 还在用」「没人说得清哪条该吊销」的人。
⛔ 不适用：只有你自己一台机器、一套 key 的个人用户 —— 对你来说三层是三层、三档是一档，直接把寿命设上、把吊销路径记住就够了。
⚠️ 前提：愿意先接受一件事 —— 这一次要动的是配置与清单，不是代码；改配置属「改变对外事实」，务必在有人能复核的时候做。
自测 · 5 问
我能说出我们选的是三档里的哪一档，以及为什么是这一档（而不是「默认就这样」）
我知道新 key 的最长寿命是多少天，并说得出这个上限是照着哪个最坏情况定的
我手上有一份存量 key 清单（含「从没设过过期」的那几条），而不只是「控制台里看着正常」
每条 key 我都能回答谁在用 —— 答不上来的那几条，已经被标出来了
我知道在哪儿吊销一条 key，并且知道吊销之后多久生效（做过一次演练最好）
怎么上手 · 验证步骤
第一次别全量动。只做一格：把「谁能建 key」这一档先定下来 —— 哪怕结论是「维持现档」，也要把决定与理由写进团队的那份说明里（改一次要有人知道）。第二步才是寿命：先给新 key 设一个宽松上限（比如 180 天），跑一轮看有没有哪个服务被卡住。第三步专门留给存量：只挑「从没设过过期 + 还没人能说清谁在用」的三条，逐条找到负责人，二选一 —— 补上过期时间，或吊销重建。这三条处理干净，剩下的照同一套复制即可。
自检动作：把设置改完之后，隔一天再取一次「实际生效清单」，与改之前的清单并排。两份对照里不一致的那几条，就是你这次真正改到的东西；如果两份完全一样，说明你可能只改了「声明」，没有改到「生效」。这一步是这一页的核心 —— 能证明配上了，才算配上。