Google AI Studio密钥9月换轨：旧Standard key会被拒绝

Google明确写明，Gemini API将在2026年9月拒绝Standard key，并要求开发者在9月前迁移；页面没有给出具体生效日。新建的Google AI Studio API key已默认为Auth key，因此Key Type仍显示Standard的密钥都应进入迁移清单，而不能仅靠现有限制长期续用。

这通常不要求改写Gemini API业务逻辑：应用仍可通过GEMINI_API_KEY读取凭据。真正容易造成中断的是遗漏某个部署、定时任务或低频服务，所以迁移顺序应是创建Auth key、替换服务端秘密、验证实际流量，最后撤销旧Standard key。

先确认哪些密钥必须迁移

Standard key把请求关联到Google Cloud项目，用于结算和配额，但不识别具体调用者；Auth key则直接绑定Google Cloud服务账号，请求以该账号身份处理，并默认仅限Generative Language API。Google的Gemini API密钥说明 同时确认，新建密钥默认为Auth key、2026年9月将拒绝Standard key，并给出了先部署替代密钥、验证后再撤销旧密钥的泄露处置顺序。

识别类型不能依赖变量名或字符串外观。进入Google AI Studio的API Keys页面，查看Key Type列，把每个Standard key对应到Google Cloud项目、服务、环境和负责人；若看不到项目，应先把相应Cloud项目导入AI Studio。

盘点范围不能只限于源码。还要检查CI/CD变量、托管平台的秘密配置、容器启动参数、预览环境、后台任务、服务器配置和独立脚本。任何曾进入公开仓库、浏览器代码、移动应用包、截图或不受控日志的密钥，都应按已泄露凭据处理。

按新旧并行顺序完成迁移

无停机迁移的核心是先让新Auth key承接调用，再撤销旧Standard key。直接删除旧密钥会把任何配置遗漏立即变成鉴权失败。

1. 在API Keys页面按Key Type找出所有Standard key，建立“密钥—项目—服务—环境”清单。
2. 在对应项目中新建API key，并确认Key Type显示为Auth。改名或给旧Standard key补充限制不等于完成迁移。
3. 把新值写入服务端的秘密存储或运行时环境，应用可继续读取原有变量名GEMINI_API_KEY，避免同时引入无关代码改动。
4. 先更新开发和预发布环境，发起真实Gemini API请求；再更新生产部署，确认新实例、修订版本和后台任务均已加载新值。
5. 检查鉴权错误、API用量、费用和低频调用路径。所有调用方验证完成后，再停用或删除旧Standard key。

回归不能只验证进程成功启动。至少覆盖一次正常生成请求，以及应用真实使用的流式响应、结构化输出、工具调用或文件输入路径；同时验证错误处理，防止把模型响应问题误判为密钥问题。迁移窗口内尽量不要同时升级SDK、切换模型或重构调用链，否则故障归因会变得困难。

AI Studio、Cloud Run和自行部署怎样保存

AI Studio Build模式：Build模式的密钥管理说明 显示，新应用会把GEMINI_API_KEY配置为服务器端秘密，密钥不会进入客户端代码；2026年5月14日以前构建的应用在下次修改Gemini功能时会升级到推荐的服务器端方式。从AI Studio部署到Cloud Run时，密钥也会进入服务器端环境；下载ZIP转到外部托管后，则要自行设置该环境变量。

Cloud Run：从AI Studio直接部署后，仍需确认实际承接流量的修订版本使用了新密钥。自行维护Cloud Run时，可把替代值保存为新的秘密版本，让新修订引用它，验证请求后再结束旧修订的流量；不要把密钥写入镜像、Dockerfile或构建日志。

自行部署：虚拟机、Kubernetes和其他托管环境应从进程环境或专用秘密管理服务读取GEMINI_API_KEY。浏览器和移动客户端不能安全保存长期API key；需要向客户端提供Gemini能力时，应由自己的后端接收业务请求并调用API。

把提示词验证与鉴权回归分开

密钥切换只应改变鉴权凭据，不应顺带修改提示词、模型或生成参数。先固定一组不含敏感数据的回归输入，并记录需要保持的响应结构、状态码和业务校验条件，才能区分鉴权失败与输出行为变化。

Google AI Studio快速入门 说明，Playground可用于试验提示词，定型后可通过Get code选择语言并导出Gemini API代码。Playground成功只能证明当前提示词和凭据能够调用API，不能证明Cloud Run修订版本、自行托管容器或后台任务已经读取新的服务端秘密。

验证可以分成两层：先用新Auth key完成最小API请求，再运行应用级回归。生产验证应覆盖真正使用的调用路径，并检查部署状态与鉴权错误；只有清单中的每个调用方都通过验证，才进入旧密钥撤销阶段。

泄露后轮换与迁移完成标准

发现泄露后，先创建替代Auth key并部署到所有调用方，确认新密钥生效后，再停用或删除泄露密钥。先撤销旧值可能导致停机，但也不能为了保险无限期保留两把有效密钥，因为这会延长泄露凭据的可用窗口。

轮换期间应核查API用量和结算记录，寻找异常调用，并为新密钥保留满足业务所需的最小权限。如果旧Standard key还被其他Google API共用，应为Gemini API新建独立Auth key，不要复制原有的共享密钥结构。

迁移完成应同时满足五项条件：清单中没有仍承载Gemini流量的Standard key；生产与低频任务均已通过Auth key回归；客户端和代码仓库不含明文密钥；旧密钥已撤销；用量与费用异常有明确的告警接收人和处置权限。缺少其中任何一项，都只能算完成了替换，不能算完成了迁移。