关键字排名查询脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f1b5abad4e5b.html
📄
关键字排名查询脚本调用工具遇到限流时怎样保护已有结果
限流发生后，先不要重跑整个任务，而是把已经拿到的那部分结果落盘、标记完成范围，再决定是等待重试还是缩小查询对象。判断依据不是“请求失败”本身，而是失败发生前有多少条记录已经完整返回、这些记录能否单独构成一份可用结果。
先确认哪些结果已经完整，哪些只是半截
限流通常不会均匀地打断所有请求。假设你的脚本按一批关键词逐条调用，前 40 条正常返回，第 41 条开始报错，那么前 40 条是完整的，第 41 条之后是缺失的。真正危险的是把一次失败当成整体失败，然后从头重跑，反而覆盖掉已经拿到的数据。
判断完整性要看三个位置：
- 请求是否返回了成功状态，而不是超时或空响应；
- 返回内容里是否包含你需要的字段，而不是只有错误信息；
- 这条记录是否已经写入本地文件或数据库，而不是只停在内存里。
如果脚本只在全部跑完后才统一写文件，限流就等于把中间结果一起丢掉。改动方式很直接：每成功一条就追加写入一次，或者每 10 条批量落盘一次。这个动作的结果是，限流后你能明确指出“已完成到第 40 条”，而不是只能重来。
把已完成范围写进状态文件，而不是靠记忆
只落盘数据还不够，还要记录进度。可以在同一目录下维护一个状态文件，写入最后成功的标识、时间戳和本次查询参数。下次启动时先读状态文件，从下一条继续，而不是从第一条开始。
这里要区分两种限流：
- 短时限流：等待一段时间后同一批请求可以继续，适合保留状态、延迟重试；
- 配额耗尽：当天或当周期内无法再调用，继续重试没有意义，应改为导出已有结果并安排下一次执行。
区分方法不是猜，而是看错误返回里是否给出可重试提示、以及等待后重试是否仍然失败。如果等待后仍然失败，就按配额耗尽处理，先保护已有结果。
用一份可交付结果替代“完整跑完”
已有结果能不能用，取决于你的查询对象。如果读者手里是一份待查的页面或关键词清单，可以把它拆成“已确认”和“待确认”两部分。已确认部分直接进入后续分析，待确认部分留到下次执行。
假设一份清单有 200 个条目，限流前完成 120 个。此时不要为了凑满 200 个而反复重试，而是先把这 120 个导出成一份带时间戳的结果文件，并在文件名或备注里写清覆盖范围。这样做的结果是，下游使用这份数据的人知道它只覆盖了前 120 个条目，不会误以为整份清单都已查询。
如果业务要求必须全量，可以把剩余 80 个拆成更小的批次，降低单次请求密度，而不是一次性重跑全部。缩小批次会拉长总耗时，但能减少再次触发限流的概率。
重试前先改变调用节奏，而不是原样再跑
限流后原样重跑，大概率再次撞上同一限制。可行的调整包括：
- 把请求间隔从固定值改为带随机波动的间隔，避免所有请求在同一时刻发出；
- 把大批量拆成多个小批次，每批之间留出等待时间；
- 对失败条目单独建一个队列，成功条目不再重复请求。
这些动作的共同结果是降低单位时间内的请求数量。代价是完成同样多条目需要更长时间。如果业务对时效要求高，就要在“更快但可能再次失败”和“更慢但更稳”之间做取舍，而不是默认重试次数越多越好。
什么情况下可以放弃本次结果
如果限流发生在任务刚开始、已完成条目很少，且这些条目本身没有单独使用价值，那么保留它们的意义不大。此时更合理的做法是记录失败原因，调整调用参数，另起一次执行。
判断标准可以简化为：已完成部分能否独立回答你当前的问题。能，就保护并交付；不能，就记录状态后重新安排。不要因为已经发出过请求，就强行把半份结果包装成完整结果。
限流本身不是数据错误，它只是调用节奏与工具允许范围不匹配的信号。先落盘、再记录进度、最后调整节奏，这三步的顺序比具体用哪种重试策略更重要。
