百度网站优化助手：脚本调用被限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /25c0c8d1e8de.html
📄
百度网站优化助手：脚本调用被限流时怎样保护已有结果
先给结论：脚本被限流后，第一优先不是立刻重试，而是把“已经拿到的结果”和“尚未拿到的任务”分开保存，并让后续流程只读取本地已完成部分。是否重试取决于限流是临时性的还是策略性的；前者可以延迟续跑，后者应改为人工分批或降低调用频率，否则已落地的结果也可能被覆盖或污染。
假设情境：一次批量查询被中途限流
假设你用脚本调用百度网站优化助手批量查询一批页面的抓取与收录状态，前 60 条正常返回并写入一个 JSON 文件，第 61 条开始连续返回限流提示。此时脚本如果直接从头重跑，可能把前 60 条重新请求一遍，既加重限流，也可能让后写入的数据覆盖前一次结果。更稳妥的做法是先停止写入，把已成功的 60 条标记为“已完成”，把第 61 条之后标记为“待处理”，再决定下一步。
两种做法：原地重试，还是冻结结果后分段续跑
原地重试适合限流提示明确为短时波动、且脚本有幂等写入的情况：同一任务重复执行不会产生重复记录，也不会覆盖不同批次的数据。代价是继续消耗调用额度，如果限流是策略性的，重试只会延长被封时间。
冻结结果后分段续跑适合限流持续、任务量大或结果需要交付给他人核对的场景：先把已完成部分落盘并锁定，再按剩余任务拆成小批，加入等待间隔后逐批执行。代价是整体完成时间变长，且需要额外维护“已完成/待处理”的状态文件。
判断依据可以看三点：一是限流提示是否在降低频率后仍反复出现；二是已完成结果是否已经具备独立使用价值；三是后续任务是否依赖前序结果。若第二点成立，优先冻结；若第一点成立，也应冻结。
保护已有结果的具体动作
第一步，立即停止当前脚本的写入操作，避免半截数据混入正式结果。第二步，把已完成结果复制到只读目录或另存为带时间标识的文件，例如 done_20240601.json，后续流程只读这个文件。第三步，记录最后一个成功任务的标识，作为续跑起点。第四步，把剩余任务写入待处理清单，并注明限流发生时的调用频率和等待时长。
这些动作的结果直接影响下一步：如果只读副本和续跑起点都明确，你可以安全地等待一段时间后从断点继续；如果没有冻结，就只能重新全量请求，既无法判断哪些结果是新的，也无法向执行人员解释数据差异。
续跑时怎样避免再次触发限流
续跑不要沿用原来的并发和间隔。可以先取待处理清单中的一小段，例如 5 到 10 条，用比原来更长的等待间隔执行，观察是否仍返回限流提示。如果这一小段顺利返回，再逐步增加批量大小；如果仍然限流，说明当前策略不适合继续自动调用，应改为人工分批处理或延长等待周期。
同时要保留每次续跑的日志，至少记录批次、时间、成功数量和失败原因。日志的作用不是证明“限流已经解除”，而是帮助区分：是调用频率问题，还是任务本身触发了额外校验。请求量归零或抓取量下降，也可能只是任务队列空了或脚本提前退出，不能单独作为限流已解除的证据。
什么时候该放弃自动续跑
如果连续多个小批次都在同一位置被限流，且降低频率后没有改善，就不要再把时间花在调参上。此时应把已完成结果交付出去，把未完成部分转为人工核对或改用其他合规的查询方式。这个取舍的代价是放弃自动化速度，但换来的是已有结果不被反复覆盖，也避免因持续请求导致更长时间无法调用。
需要提醒的是，百度网站优化助手的具体限流规则、返回提示和可用调用方式可能随平台调整，脚本编写前应核对当前官方说明和账号权限，不要依据旧版行为推断现行限制。
