搜到「google 搜索 api」就准备开干的人，多半会在两个地方卡住：一是以为它跟普通大模型 API 一样按 token 收，二是把返回结果当自家数据随便存。这篇不讲原理，只给判断标准和能照着做的检查动作，帮你在写第一行代码前把账和边界都定下来。
搜到「google 搜索 api」就准备开干的人，常常在同一个地方栽跟头：把它当普通大模型 API 理解。按 token 估成本，按每千次调用算预算，结果账单出来发现根本不是这回事。另一种常见情况是结果拿到手就往数据库里灌，灌了两周才想起来问一句「这玩意儿能存吗」。
这篇不讲原理，只讲你写第一行代码之前必须定下来的几件事：钱怎么算、配额算谁的、结果能用到什么程度。每一条都给判断标准，你对着自己的场景过一遍就能落地。
先搞清它按什么收钱，别套 token 那套
搜索类接口的计费单位是「一次查询」，跟大模型按输入输出 token 计费完全不是一套逻辑。你没法通过「精简 prompt」来省钱，因为一次查询就是一次查询，返回十条还是三条，单价都一样。所以成本估算的第一步不是看单价，是估自己一个月会发出多少次查询。
分档定价在这种接口上很普遍：月查询量落在不同区间，单价不一样。先把自己的量级算出来，再去对照档位，才知道贵不贵。反过来先看单价再倒推用量，容易算出一个自己都实现不了的预算。当期官方口径到 /official-api/providers/google 核对，别拿记忆里的数字做方案。
- 确认计价单位是「每次查询」还是「每次请求」，带分页的接口翻页算不算新的一次，这条不问清楚后面全是糊涂账
- 图片、新闻、地图这类独立能力往往单独计价，不能拿主搜索接口的单价直接乘
- 分页翻页、结果条数参数是否影响计费，各家规则不同，看文档里的计费说明那一节
- 先按月查询量估算，再对照档位，最后才评估单价高低
配额和限额归属：账号、项目还是 key
配额一般绑在云项目上，不是绑在单个 API key 上。这意味着团队里几个人共用一个项目时，谁跑一次批量任务，整组人的额度一起掉。测试同学压测跑嗨了，线上同事那边直接开始报错，这种事故一点都不少见。
还有三件事容易混：免费额度、每日限额、QPS 限速。它们触发后的表现完全不一样。免费额度用完是开始计费还是直接拒绝，看你的账号配置；每日限额是当天封顶；QPS 限速是每秒并发超了就拒。重试逻辑要按这三种情况分开写，一股脑指数退避会把限速问题拖成雪崩。
| 限制类型 | 触发后的典型表现 | 建议处理 |
|---|---|---|
| 免费额度耗尽 | 可能转为计费，也可能直接拒绝 | 上线前确认识别方式，日志里打标记 |
| 每日限额 | 当天后续请求全部失败 | 做日用量监控，接近阈值时告警 |
| QPS 限速 | 瞬时并发超限被拒 | 客户端加令牌桶，重试带抖动 |
| 单次请求参数超限 | 参数错误类报错 | 入参校验前置，别等接口拒 |
多环境建议直接拆项目：测试一个、生产一个。不拆的话压测流量会算进线上账单，而且限额互相挤占，排查问题时根本分不清是谁在消耗。
返回结果能不能存、能存多少
搜索结果里夹着大量第三方内容，能不能落库、能保留多久，取决于服务条款，不取决于你的技术水平。技术上你能把整个响应体存下来，条款上未必允许。拿不准的时候，保守做法是只存结果 ID、标题、摘要和跳转链接，正文内容不落地。
做缓存尤其要小心。缓存能省钱也能提速，但缓存时长常有上限，能不能缓存本身也要看条款。把缓存策略写进设计文档，比上线后被问起来再补要省事得多。展示给终端用户时，来源署名和可点击的原始链接别省，这既是条款要求，也是用户判断信息可信度的依据。
- 翻一遍服务条款里跟「存储」「缓存」「展示」相关的段落重点看有没有保留时长限制、有没有禁止长期存储的表述，逐条记进设计文档
- 定一个最小存储字段集先按「ID + 标题 + 摘要 + 链接」设计表结构，正文不入库，后续真有需求再评估
- 给缓存加显式过期时间代码里写死过期时长并注释条款依据，别用框架默认的永不过期
- 在展示层校验署名和链接终端页面上每条结果都必须能点回原始来源，缺了这条就不算做完
上线前照着过一遍的六项检查
前面几节定的是口径，这一节是动手验证。口径对不对，跑一轮真实查询就能暴露大半问题。别用「hello world」这种词测，用你业务里真实会出现的查询词，包括那些一看就会出问题的。
成本这块要在日志里留痕。每次调用记一笔查询类型、是否分页、耗时、消耗档位，月底对账时才有依据。字段怎么设计，可以参考 /tools/model-cost-calculator 的拆解思路，把「一次查询」当成最小核算单元，而不是把整月账单摊到每天。
- 真实查询词跑三类：正常词、空结果词、超长或带特殊字符的词，看返回结构会不会变形
- 错误码分类处理：限速、额度耗尽、参数错误分开重试，别统一指数退避
- 单次调用成本写进日志字段，按查询类型拆开，方便月底核对
- 直连官方和走中转站各测一轮延迟，到 /tools/speed-test 量出基线再定超时阈值
- 测试环境和生产环境确认已拆项目，压测不会挤占线上额度
- 条款里关于存储和展示的要求，逐条在代码或文档里找到对应实现
这六项里最容易漏的是最后一项。前面五项跑一遍就有反馈，条款对照却是纸面工作，容易拖到上线后才想起来。建议把它放进上线检查单，跟其他项一样打勾才算完。
搜索接口的钱按查询算，配额按项目算，结果按条款用——这三件事在写代码前定下来，后面能少返工一大半。下一步去站内核对当期官方计费口径和模型资料，再拿真实查询词跑一轮，把成本字段和错误分类补进代码。→
常见问题
免费额度用完了会直接扣钱吗
看账号有没有绑结算方式。多数云平台在免费额度耗尽后，如果已开通计费就会继续按量扣，没开通则直接拒绝。稳妥做法是先在控制台设预算告警，别等账单出来才发现。
搜索结果能直接存到自己数据库吗
技术上都存得下，条款上不一定允许。先把服务条款里关于缓存、存储时长的段落读一遍，再决定存全文还是只存链接加摘要。不确定就按最保守的方案设计。
走中转站和直连官方，注意事项一样吗
计费和配额口径会变。中转站可能有自己的倍率和限速规则，排查顺序也得跟着改：先确认是上游限流还是中转侧限流。可以到 /rankings 看当期对比再决定。
