快速结论
当前文档列每账号 Search 100 QPS、Fetch 25 QPS；换 Key 不增加额度，Fetch 仍有域名限制。QPS 不等于固定并发数量。
- Search 与 Fetch 的账号额度彼此独立。
- Fetch 的目标域名限制也可能触发 429。
- 402 先处理余额，其他多数 4xx 需修改请求再试。
本次更新：修订摘要、快速结论与正文中的旧限额，补充分开配置速率与并发。
本教程按 10 月 20 日官方网页搜索与抓取文档核对。以下队列结构为应用设计建议，不是接口自带的配置项。
两层限制分别处理
当前文档列 Search 每账号 100 QPS、Fetch 每账号 25 QPS，和模型并发限制独立。多个进程共用一个账号时，需要共享限速记录；换 API Key 不会增加该账号的额度。Fetch 还有目标域名的 QPS 限制，文档未公布一个可套用于所有目标域名的 QPS 数字。
可建立 Search 账号队列和 Fetch 账号队列，再让 Fetch 按目标主机分组。即使账号请求数不高，同一个站点的集中抓取仍可能遇到限制。
错误分类决定下一步
| 响应 | 官方文档给出的方向 | 应用侧建议 |
|---|---|---|
| 408、429、5xx | 等待后重试 | 逐步增加等待，加入随机抖动并设总次数上限 |
| 402 | 先充值再重试 | 暂停队列，通知负责账号的人 |
| 其他 4xx | 不修改请求则不要重试 | 检查参数、权限及接口地址 |
不要让所有 worker 在同一时间立即重发。可以从保守的并发和速率开始，通过日志观察响应后调整；本文不为目标域名假设一个未经公布的固定阈值。
批量抓取先去重，再排队
搜索结果可能出现重复 URL。应用可在抓取前去重，并给缓存记录添加抓取时间，过期后再刷新。页面抓取成功后也要检查内容是否可用，避免把登录页或错误正文送入后续总结。
count 控制搜索返回条数，不能提高请求额度，也不改变单次请求价格。费用统计与限速统计分别记录，完整口径见Search / Fetch 计费指南。
10 月 20 日修订说明
本站此前写为两者各 5 QPS，现按当前中英文官方指南修订。具体调整生效时间尚未确认。请求速率与并发请求数分别设置：响应时间较长时，在途请求仍可能积压，不能把 QPS 数字直接作为唯一的并发配置。
参考资料
本文依据以下资料整理，版本与接口信息请以来源页面的现行说明为准。
阅读至此返回学习中心