百度排名优化工具：脚本调用被限流时怎样保住已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e41658c71e16.html
📄
百度排名优化工具：脚本调用被限流时怎样保住已有结果
结论先给：如果脚本只是被临时限流，而历史结果已经落盘且能按批次追溯，正确动作是停止继续调用、把已有结果冻结成只读快照，再单独安排复核；如果历史结果和本次被限流的请求混在同一个数据表里、没有批次标记，那么先别急着跑下一轮，优先把已有结果拆出来隔离，否则下一轮写入会覆盖或污染旧结论。判断依据不是“限流是否解除”，而是已有结果是否可追溯、可复现、可区分。
先分清两种限流：请求级限流和账号级限流
请求级限流通常表现为单个接口或单个动作在短时间内被拒，换一个时间窗口或降低并发后可能恢复。账号级限流则会影响同一凭证下的多个调用，甚至牵连到工具后台的其他读取动作。两者的处理顺序不同。
- 请求级限流：先停脚本，保留当前批次，记录被拒时间点和已完成的条数，不要立刻重试。
- 账号级限流：不要换凭证硬跑，先把该账号下所有脚本暂停，避免把限流范围扩大到其他任务。
这里有一个容易误判的点：调用返回失败，不等于结果无效。已经成功返回并写入的数据仍然可用，前提是你知道它属于哪一批、对应哪个参数组合。
冻结已有结果的三个具体动作
第一步，把当前结果表另存为只读快照，文件名带上日期和批次号，例如 rank_20240612_batch07。第二步，在快照里补一列“采集状态”，标记每条结果是完整返回、部分返回还是被限流中断。第三步，把脚本的写入目标从原表切换到新表，原表只读，不再接收新数据。
做完这三步，下一步动作才成立：你可以安全地等待限流窗口过去，再决定是补采缺失部分，还是整批重跑。如果没有做隔离，直接重跑会把新旧结果混在一起，之后无法判断某条数据是限流前的还是限流后的，复核成本会明显上升。
什么情况下“保住已有结果”这个结论会失效
反例很明确：如果已有结果本身就是脚本在参数错误、页面结构变化或登录态失效的情况下采集的，那么它虽然完整，也不能作为后续决策依据。这时“冻结”只是防止继续污染，不代表这批结果可用。
区分方法可以看两个证据：一是同一批结果里是否存在大量结构相同但数值异常的记录；二是把其中几条与人工抽查结果对照，偏差是否集中在某一类页面上。如果偏差集中出现，说明问题不在限流，而在采集前提已经变了，应该先修正参数或解析规则，再谈补采。
一个注明假设的处理顺序
假设你有一批关键词排名结果，脚本在写到第 300 条时被限流，前 300 条已成功落盘，第 301 条开始失败。此时不要直接重跑全量。先冻结前 300 条并标记批次，再检查失败是从固定位置开始，还是随机出现。如果是固定位置，可能是该位置对应的查询触发了更严格的限制；如果是随机出现，更可能是整体频率过高。两种情况的下一步不同：前者需要调整查询拆分方式，后者需要拉长调用间隔。这个例子的数字只用于说明比较方法，不代表任何真实项目的规模。
限流解除后先复核，再决定是否补采
限流解除不等于可以立刻全量重跑。先做小范围复核：从冻结快照里抽几条，用人工方式或低频调用重新确认，看结果是否一致。如果一致，说明已有结果可信，只需要补采被中断的部分；如果不一致，说明限流期间外部条件已经变化，补采前要先确认变化来源。
最终判断标准是：已有结果能否支撑你当前的决策。如果能，就不要为了“跑完整”而冒险覆盖；如果不能，也要在隔离旧结果之后再重跑。把这两件事分开做，才不会在限流恢复后把之前的可用数据一起赔进去。
