google gemini api key 购买

很多开发者第一次碰 Gemini，卡的不是代码，而是 Key 从哪弄：官网走不通、支付过不去、拿到的 Key 到底能不能用也说不准。这篇按「先确认路径、再落地调用、最后排错」的顺序走一遍，帮你把一条能跑的链路搭起来。具体价格和模型规格不写死，去站内对应页面看当时的数字。

很多开发者第一次碰 Gemini，卡的不是代码，而是 Key 从哪弄：官网走不通、支付过不去、拿到的 Key 到底能不能用也说不准。这篇按「先确认路径、再落地调用、最后排错」的顺序走一遍，帮你把一条能跑的链路搭起来。具体价格和模型规格不写死，去站内对应页面看当时的数字。

先说清楚一件事：这篇不推销某一条路，而是把三条常见来源的判断标准摆出来，你自己按团队情况选。选完之后的绑定动作、验证动作、排错顺序，三条路基本通用，换渠道不用重学一遍。

先搞清楚 Key 有哪几种来源

国内开发者能拿到 Gemini Key 的路子大致就三条，门槛和代价各不相同，别一上来就冲官网。先想清楚你后面要不要开发票、要不要固定出口 IP、能不能接受 Key 经第三方中转，这三条基本决定你该走哪条路。

判断标准可以简单点：如果这条 Key 要进生产、要进财务流程，优先走前两条；如果只是本地验证想法、跑个 demo，中转站上手最快，但心里要清楚它默认不是长期方案。中转站的可信度怎么打分，站内有专门的检测逻辑和维度说明，别只看宣传页上的承诺。

动手前把这几样准备好

注册环节掉链子，九成是准备不足，不是流程复杂。把下面这几样提前弄好，能省掉来回折腾的时间。

• 一个能稳定收验证码的邮箱，和一个能接短信的手机号，别用一次性邮箱，风控容易拦
• 支付方式：官方通道对卡种和账单地址有要求，提前确认，而不是最后一步才发现失败
• 代码侧：选定语言的 SDK、环境变量存放位置、一条最小可跑的测试脚本
• 存放习惯：Key 进环境变量，不进代码仓库，团队协作时这条更要紧

团队场景下 Key 怎么分、谁能看、出事怎么收回，这些属于权限治理的范畴。站内 /guides/shared-key-risk-control 讲了共用 Key 的风险切分思路，接生产之前值得过一遍，个人本地跑 demo 可以暂时跳过。

拿到 Key 之后怎么绑、怎么验

1. 写进环境变量把 Key 放到 .env 或系统环境变量里，代码只读变量名，不读明文，验证方式是 grep 一遍仓库确认没有硬编码。
2. 发一条最小请求用最简的调用跑通一次，不要一上来就套业务逻辑，变量越多越难定位。
3. 打印返回字段把实际返回的模型名和用量字段打出来，这是判断中间有没有转手的第一手证据，光看 HTTP 200 不够。
4. 测一次延迟基线到 /tools/speed-test 跑一次，知道自己当前网络大概什么水平，后面出问题时有对照。
5. 比对真实模型同一段提示词换不同来源的 Key 各跑一次，看输出风格和用量口径是否一致，落差大就说明有中间环节。

验证有边界：如果你只是本地做原型、不涉及线上流量和真实用户数据，审计类、配额切分类的配置可以先不做，没必要一上来就上全套。但一旦要对外提供服务，上面几步里「打印返回字段」和「比对真实模型」不能省。

调不通的时候按这个顺序排查

排错最怕东试一下西试一下，越试越乱。按下面的顺序走，每一步只改一个变量，出问题也好回退。

401 / 403

先看 Key 有没有多余空格或被复制时截断，再看这个项目有没有开通对应接口的权限

请求超时

先换网络出口，再换 Key 来源，两步基本能区分是本地网络问题还是渠道问题

能返回但内容不对

优先怀疑模型被替换，用固定提示词反复跑几次，看输出是否稳定、风格是否和官方一致

要留证据

把请求时间、返回内容、用量数字记下来，后续找渠道对账或换站都用得上

比对模型这件事别凭感觉。站内 /tools/verify 这类在线实测工具可以帮你把「同一提示词、不同来源」的差异量化出来，比自己眼估靠谱。另外，同一个 Key 在不同时间段的用量口径也可能变，长期用就要定期复核，而不是验一次就完事。

如果你已经决定要换来源，别急着把旧 Key 删掉，先让新旧并行跑一段、数字对得上再切，中间那段时间的对照数据就是你的依据。价格和模型规格这类会变的东西，去 /price-watch 核对当时的数字，别拿几个月前的印象做决策。