百度权重查询：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6e15051161cb.html
📄
百度权重查询：脚本调用工具遇到限流时怎样保护已有结果
结论先说：如果脚本已经拿到了部分结果，限流发生时最该保护的不是“继续跑完”，而是“让已完成部分可恢复、可复用、可验证”。做法是把每次查询结果先落盘并记录状态，再让脚本从断点继续；这样限流只影响进度，不会让前面已消耗的调用作废。反之，如果脚本把全部结果攒在内存里、最后统一写出，一旦中途被限流中断，已查到的数据会一起丢失，此时任何重试都等于从头再来。
先判断限流是“拒绝服务”还是“要求放慢”
两种情况的处理方向不同。若返回明确提示请求过频、要求稍后再试，通常属于速率型限流，降低并发、拉长间隔后往往能继续；若返回的是鉴权失败、额度用尽或账号被限制，则属于资格型限流，继续重试只会加重问题。判断依据应来自响应内容本身，而不是“跑不动了”这个感受。
一个可区分的证据是：把并发降到很低、间隔拉长到明显超过平时节奏后重试，如果恢复出数，说明是速率问题；如果仍然稳定失败，更可能是额度或权限问题。这一步直接影响下一步——速率型可以自动退避重试，资格型应当停止脚本并转人工核对。
让结果先落盘，再谈重试
保护已有结果的核心动作是边查边写。每完成一条或一小批查询，就把结果追加写入本地文件或数据库，并同时记录这条记录的状态，例如成功、失败、待重试。这样限流中断后，脚本读回文件就能知道哪些已完成、哪些还没做。
具体可以这样做：
- 为每条待查目标分配稳定标识，而不是依赖数组下标，避免顺序变化后对不上。
- 结果写入采用追加方式，写完一批再更新进度标记，避免进程被杀时留下半条记录。
- 把原始响应和解析后的字段分开保存，解析规则变化时还能回到原始数据重算。
- 重试时只处理状态为失败或待重试的条目，已完成的不再重复请求。
这样做的直接结果是：限流造成的损失被限制在“当前这一批”，而不是全部。下一步的断点续跑也就有了可靠依据。
退避重试要带上限，不能无限等
遇到速率型限流，常见做法是失败后等待一段时间再试，且等待时间逐次拉长。但如果没有上限，脚本可能在额度已耗尽时一直空转。合理设置是：给定最大重试次数和最大等待时长，超过就停止并把剩余任务标记为未完成。
假设一个脚本有 200 条待查目标，已成功写入 120 条后开始被限流。若设置了三次退避重试仍失败就暂停，那么脚本会保留这 120 条结果并退出，而不是清空重来。恢复时只处理剩余 80 条。这个例子只用于说明比较方法，实际阈值需按自己的调用节奏和返回提示调整。
需要提醒的是，请求量下降或某次抓取归零，并不能单独证明限流已解除。它也可能是目标本身无数据、脚本提前退出或筛选条件写错。判断是否恢复，应看新请求的响应是否正常返回，而不是只看数量变化。
什么情况下这套做法会失效
反例是：查询结果本身依赖跨条目的上下文，必须全部拿到后才能计算，例如需要先汇总全部目标再统一排序或去重。此时“边查边写”只能保住原始数据，无法保住最终结论，中途限流仍会让整体交付推迟。遇到这种情况，应把“原始结果”和“汇总结果”分成两个阶段，先保证原始结果可恢复，汇总阶段再单独重跑，而不是把两者绑在一次调用里。
另一个会失效的条件是：结果没有稳定标识，重跑时无法判断某条是否已经查过。这种情况下即使落了盘，也可能重复请求或漏查。补救办法是先补齐标识规则，再开始批量调用。
下一步动作
先停掉当前脚本，不要立即全量重跑。检查已写入的结果文件，统计成功条数和失败条数，确认标识是否唯一。然后修改脚本，加入边查边写、状态记录和带上限的退避重试，再只针对未完成部分恢复运行。这样限流带来的影响会从“全部白跑”缩小为“少跑了一部分”，已消耗的调用也能继续使用。
