排名工具，脚本调用遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /da5abf6ca990.html
📄
排名工具，脚本调用遇到限流时怎样保护已有结果
限流发生时，先别重跑全量。把已有结果按“可复用、可改写、可退出”三类分开：能直接留用的落盘冻结，只能作参考的降级标注，已经失效的停止继续消耗配额。这样做的直接结果是：即使脚本被限流，你仍然知道哪些数据能支撑下一步决策，而不是面对一批真假不明的旧结果。
先判断限流是配额问题还是结果本身出了问题
限流提示只是表象，背后至少有三种不同原因，处理方式完全不同。
- 调用频率触发：短时间请求过密，等待后恢复即可。此时已有结果通常仍然有效，不应因为限流就全部作废。
- 配额耗尽：当日或当周期额度用完，需要等到重置。已有结果依然可用，但要标注抓取时间。
- 账号或权限状态变化：接口返回的拒绝可能被误读成限流。这种情况下降级重试没有意义，应该先确认权限状态再决定是否继续。
一个可区分的证据是：如果同一批请求里只有部分失败、间隔重试后能成功，偏向频率问题；如果全部失败且重试无效，更可能是配额或权限问题。请求量突然归零不能单独证明脚本写对了，也可能是目标端调整了响应方式，需要结合返回内容判断。
保留：把已经拿到的结果变成可冻结的资产
限流最怕的不是拿不到新数据，而是把旧数据和新数据混在一起，导致无法判断哪条是哪次抓的。保护已有结果的第一步是加时间戳和批次标识，让每条记录能追溯到具体抓取时刻。
假设一批查询中前 60% 成功、后 40% 被限流。此时不要删除失败部分重跑，而是把成功的 60% 单独存档，并记录失败项的关键词和位置。下一步只需补抓那 40%，而不是从头再来。这个动作的价值在于：补抓量变小，再次触发限流的概率随之下降。
需要保留的字段建议包括：查询词、抓取时间、结果位置、返回状态。缺少返回状态的记录无法区分“确实没有结果”和“当时没抓到”，后续决策会被误导。
改写：哪些旧结果还能用，哪些必须重抓
不是所有旧结果都值得保留。判断标准是结果对时间有多敏感。
- 可以改写留用：用于观察长期趋势的历史序列。只要标注时间点，旧值仍然能反映变化方向。
- 需要重抓：用于判断当前状态的单点结果。位置、可见性这类信息变化快，旧值直接引用会得出错误结论。
- 建议退出：已经确认失效的查询词、已经下线的对象、已经终止的合作关系。继续为它们消耗配额没有产出。
操作上可以给每条记录加一个“时效等级”字段：稳定、易变、已废弃。限流恢复后，只对“易变”部分重新调用，“稳定”部分直接沿用，“已废弃”部分从任务队列移除。这样一次限流反而帮你清理了无效任务。
限流恢复后的重试顺序会影响结果可信度
恢复后不要按原始顺序无差别重跑。优先补抓失败项中时效等级为“易变”的部分，其次是失败项中的“稳定”部分，最后才考虑新增查询。
原因是：失败项本身已经证明是脚本覆盖范围内但未完成的部分，补完它们能让整批数据完整；而新增查询会扩大调用量，在配额刚恢复时更容易再次触发限制。先补完再扩量，是更稳的顺序。
重试时把并发降下来、间隔拉长，并记录每次重试的返回状态。如果同一项连续多次失败，应停止重试并标记为待人工确认，而不是无限循环。无限重试既消耗配额，也会让失败原因被淹没在日志里。
把这次限流变成下一次的防护条件
处理完当前批次后，值得回头补两件事：一是把本次触发限流的调用量和时间窗口记下来，作为下次设置间隔的参考；二是把“已废弃”任务真正从脚本配置中删除，而不是留在列表里靠判断跳过。
需要说明的是，不同排名工具对调用频率、配额重置和权限状态的处理方式并不相同，具体规则要以你所用工具的当前说明为准，不能拿旧截图或旧文档当依据。本文给出的分类和重试顺序是通用原则，落地时还需结合你实际拿到的返回信息调整。
