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