百度关键词排名查询，脚本被限流后怎样保住已经跑出来的结果

📍 WDQWDWQD987AAAAA:136.243.57.164
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /488ca04c85dd.html
📄

核心做法是把“查询”和“保存”拆成两个独立步骤：每拿到一条结果就立刻落盘，限流只影响后续请求，不影响已写入的数据。判断是否该继续跑，看的不是脚本有没有报错，而是已保存结果覆盖了多少目标词、失败词能否被单独重跑。如果做不到逐条落盘，限流一旦触发，内存里的结果很可能整批丢失。

先分清两种限流：请求被拒和连接被断

这两种情况的应对方式不同，直接决定你要不要保留当前进程。

请求被拒通常表现为返回错误码、空结果或提示频率过高。此时脚本进程还活着，已抓到的数据仍在内存里，正确动作是立即停止发起新请求，把内存中的结果写入文件，再决定是否等待后重试。

连接被断表现为超时、连接重置或进程被强制结束。这种情况下内存数据基本无法抢救，唯一能依靠的就是此前已经落盘的部分。如果你的脚本从头到尾只在结束时写一次文件，这一批就等于白跑。

可区分的原因证据很简单：看日志里最后一条成功记录的时间戳，和报错时间是否接近。如果两者相隔很近，说明限流来得突然，落盘频率就是关键；如果中间已经空转了很长时间，说明请求早就失效，只是脚本没识别出来。

当目标词只有几十到几百个、单次重跑成本不高时，不必设计复杂的容错，只需要让脚本支持跳过已完成的部分。

实施动作：把每个词的处理状态写进一个结果文件，字段至少包含词、查询时间、状态（成功/失败/待处理）。脚本启动时先读这个文件，只处理状态不是成功的词。

这样做的影响是：限流后你不需要判断“丢了哪些”，直接重跑即可，脚本自己会跳过已有结果。代价是每次启动多一次文件读取，对规模不大的任务是可接受的。

边界在于：如果查询结果本身会随时间变化，跳过旧结果意味着你拿到的是不同时间点的混合数据。此时要么接受这种混合，要么给结果加时间戳并在分析时按批次区分，不要把它们当成同一时刻的快照。

当目标词上千、单次跑完需要较长时间时，重跑代价高，重点转向“任何时刻中断都不丢已完成的部分”。

实施动作分三步。第一，把词表切成固定大小的分片，例如每片一百个词，每个分片单独一个输出文件。第二，每成功查询一个词就追加写入当前分片文件，而不是攒够一批再写。第三，记录当前处理到哪个分片、哪个位置，作为下次启动的起点。

这样做的结果是：限流发生时，最多损失当前这一条正在处理的词，之前所有成功结果都已落盘。恢复时从断点继续，不需要重新查询已经完成的词。

短例子（假设）：假设你有一千个词，分成十个分片。跑到第六个分片中途被限流，前五个分片文件完整，第六个分片保存了前几十条。恢复时只需从第六个分片的断点继续，前五百多条不需要重查。这个数字只是说明分片粒度如何影响重跑量，实际重跑量取决于你的分片大小和落盘频率。

请求量归零或抓取量下降，可能有多种解释：确实是限流生效，也可能是脚本自身出错、网络中断、或者目标页面结构变化导致解析失败。仅凭请求量下降不能证明限流已经解除，也不能证明你的处理方式正确。

更可靠的判断方式是做一次小规模试探：从待处理词里取少量词，按正常间隔请求，观察是否稳定返回可用结果。如果试探通过，再逐步放大到正常速率；如果试探仍然失败，继续等待，不要直接恢复全量。

同时检查失败词列表。如果失败集中在某类词或某个时间段，可能是查询方式本身触发了限制，而不是单纯的频率问题。这种情况下调整请求间隔未必有效，需要先确认失败模式再决定下一步。

个别样本跑通，不代表规模化后仍然成立。小规模测试时可能因为请求量低而没有触发限流，一旦放大到全量就出现例外。因此不要把“测试通过”当成“可以全速跑”的依据。

另外，逐条落盘会增加磁盘写入次数，在极大规模下可能成为瓶颈。如果写入本身拖慢了查询节奏，反而更容易触发限流。此时可以把落盘改为小批量追加，但批量大小要控制在“中断时最多损失少量结果”的范围内，而不是等到全部跑完再写。

最后，保存下来的结果只代表查询当时的状态，不能直接当作长期结论。用于决策前，需要确认数据的查询时间，并判断这个时间窗口是否仍然适用于你要回答的问题。