权重查询：脚本限流时怎样保护已有结果并决定是否续跑
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d55e079b2d1.html
📄
权重查询：脚本限流时怎样保护已有结果并决定是否续跑
先停掉自动重试，把已经落盘的原始响应和当前游标保存下来，再判断限流是暂时的还是配额已经耗尽。只要原始结果还在，后续换用更低频的调用或人工补查都能接着做；一旦让脚本在限流后继续循环，最危险的不是报错，而是旧结果被覆盖、分页游标丢失，最后连已经拿到的部分都无法复原。
先确认限流发生在哪一层
同样是脚本报错，处理方式并不一样。你要先看返回内容里有没有明确的限流信号，例如状态码、重试等待时间或配额提示；如果只是连接超时、DNS 失败或目标站返回空内容，那更可能是网络或对方临时不可用，而不是配额被打满。
可以按下面这组证据区分：
- 返回体明确提到请求过多、超出配额或要求稍后重试，并且每次调用都稳定复现，偏向限流。
- 只有部分请求失败，换一个时间点或换一条网络出口就恢复，偏向链路波动。
- 失败前调用量突然上升，且同一账号下其他脚本也同时失败，偏向共享配额被耗尽。
这一步的产出不是结论，而是一个标记：把本次任务标成“限流待恢复”或“链路待重试”。标记不同，下一步动作完全不同。
限流发生后先做三件事，而不是继续重试
假设你手里有一个正在跑的查询脚本，它按分页逐条请求，每页结果写进同一个结果文件。限流出现时，建议按顺序做这三步。
- 立即停止循环。让脚本在捕获到限流信号后退出，而不是进入无限重试。重试次数越多，配额恢复越慢，已有结果被覆盖的窗口也越长。
- 把当前状态单独写盘。至少保存三项：已成功返回的原始内容、最后成功的分页游标或偏移量、本次任务的开始时间和已调用次数。不要只保存清洗后的字段，原始响应才是后面复核口径的依据。
- 给结果文件加只读或版本标记。例如把当前文件改名为带时间戳的副本，新任务写入新文件。这样即使后续脚本出错，也不会动到已经拿到的部分。
一个假设的例子：脚本计划请求 200 页，在第 63 页被限流。如果你在退出前把第 1 到 62 页的原始响应和“下一页从 63 开始”写入状态文件，那么恢复时可以只补第 63 页之后的内容。如果没有保存游标，就只能从头再跑，既浪费配额，也可能因为目标数据已经变化而让前后两段结果对不上。
已有结果能不能直接用于决策
限流后最容易犯的错，是拿一份不完整的结果当成完整结论。判断能否使用，看两个条件是否同时成立：
- 覆盖范围是否满足你的判断需要。如果你只关心整体分布，缺失尾部若干页可能影响有限；如果你要逐条核对或做排名对比，缺页就意味着结论不成立。
- 缺失部分是否可能系统性偏离。如果脚本按某种顺序请求，被限流截断的位置恰好集中在某一类对象上，那么剩下的部分就不能代表整体。
这两个条件只要有一个不满足，就应该把当前结果标为“部分数据”，只用于排查和预估，不用于对外结论。反过来，如果缺失比例很小、截断位置随机、且你的判断只依赖大体趋势，可以先使用，但在交付时注明数据截止到哪一页。
决定续跑、换策略还是转为人工
恢复之前，先根据限流的性质选择路径，而不是直接重跑脚本。
- 限流是短时的：等待返回提示中的时间后，从保存的游标继续，并降低单次请求频率。续跑时先只补一小段，确认不再触发限流，再决定是否放开。
- 配额已经耗尽：继续调用通常没有意义。此时应把任务拆到下一个可用周期，或改用更少的请求覆盖同样的范围，例如合并分页、减少重复查询。
- 限流反复出现且无法预测：考虑把脚本改为低频批处理，或对关键部分转人工核对。人工的成本更高，但能避免脚本在限流和重试之间反复消耗已有结果。
这里有一个取舍：降低频率能保护配额，但会让任务周期变长；如果业务等不起，就需要缩小查询范围，而不是提高频率硬跑。选择哪一种，取决于你的结果是要当天用，还是可以隔天补齐。
把处理过程固化成可复用的检查点
下一次再遇到限流，能不能快速恢复，取决于这次有没有留下可读的状态。建议在脚本里固定两个检查点：每次成功请求后更新游标，每完成一个批次后落盘一次结果。这样即使进程被中断，损失也只是一个批次，而不是整次任务。
同时，给结果文件写一个简短的说明，记录数据来源、请求时间范围、已覆盖的页数和缺失部分。这份说明不需要复杂，但能让接手的人判断这份结果处在什么状态。限流本身不会毁掉已有结果，真正会毁掉结果的是没有保存状态就继续重试。
