网站测速工具脚本调用遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2db3d0c93de8.html
📄
网站测速工具脚本调用遇到限流时怎样保护已有结果
先给结论：限流发生时，优先保住已成功返回的那部分结果，并把“失败”和“未执行”分开记录，而不是立刻重试整个任务。只有当你确认限流是短时的、且失败项数量很少时，才值得做原地重试；否则重试会消耗掉本已有限的配额，让已有结果也拿不回来。
判断先保结果还是先重试的两个条件
这两种做法都成立，但成立的前提不同。选择“先保结果”的条件是：任务里包含大量待测 URL、单次调用成本高、或限流窗口较长。这时把成功结果先落到本地文件，再单独维护一份失败清单，下一步才有可用的输入。
选择“先重试”的条件是：失败集中在极少数条目、限流提示明显是短周期（例如按秒或按分钟计数）、并且重试不会挤掉后面还没跑的条目。如果重试会占用同一配额池，那它就是在和未执行的任务抢资源。
一个可区分的证据是看失败的时间分布。如果失败集中出现在某一段连续调用里，之后又恢复正常，更像短时窗口限流；如果从某个点开始持续失败，则更像配额耗尽或调用频率长期超限。前者可以小范围重试，后者必须先停下来。
把结果落盘时至少要保留哪些字段
保护已有结果的关键不是“存下来”，而是存得能续跑。建议每条记录至少包含：目标标识、调用发起时间、返回状态、耗时或指标值、以及本次调用所用的参数组合。参数组合尤其重要，因为限流后你可能调整并发或间隔，参数变了，新旧结果就不该混在一张表里比较。
- 成功项单独写一个文件，追加写入，避免中途覆盖。
- 失败项写另一个文件，标注失败原因类型，而不是只写“失败”。
- 未执行项单独列出，不要和失败项混在一起。
- 记录每批调用的开始与结束时间，便于事后判断限流窗口。
这样做的实际结果是：下次续跑时你只需要读未执行项和可重试的失败项，成功项不再重复调用。这一步直接决定了后续是补跑还是重跑，也决定了配额花在哪里。
一个假设的续跑例子
假设一次脚本任务要测 500 个地址，跑到第 180 个时开始连续返回限流提示。此时已经成功的 170 条如果只存在内存里，进程一退出就没了；如果已追加写入文件，就保住了。剩下的处理可以这样安排：把第 171 到 180 条记为失败并附上原因，第 181 到 500 条记为未执行。
下一步动作是先降低并发或拉大调用间隔，然后只对失败项和未执行项续跑。这里数字只是用来说明比较方法，不代表任何工具的真实配额。若续跑时失败项再次集中出现，就说明限流条件没有真正缓解，应停止重试而不是继续加次数。
什么情况下这个结论会失效
如果失败原因根本不是限流，而是目标地址本身不可达、参数写错、或返回内容无法解析，那么“先保结果、再补跑”就救不了这些条目——它们重跑多少次都会失败。反例是：某批调用全部返回同一类错误，且错误信息与频率无关，这时应该先检查参数和解析逻辑，而不是调整调用节奏。
另一个会让结论失效的情况是：工具本身不提供可区分的错误类型，所有异常都长一个样。此时你无法判断是限流还是别的问题，只能先做小样本探测，用少量调用验证当前条件是否恢复，再决定是否续跑。
落地时的具体顺序
- 调用前先确定结果文件的写入方式，确保中途中断也不丢已成功项。
- 捕获异常时按类型分类，至少区分限流、参数错误和网络错误。
- 限流出现后停止新调用，先写盘，再评估失败项的分布。
- 根据分布决定是短时等待后重试，还是调整间隔后整体续跑。
- 续跑只针对失败项与未执行项，成功项不重复调用。
把这几步固定成脚本里的默认行为，限流就不再是“整批白跑”的事件，而只是任务被切成两段执行。真正需要你临场判断的，只剩失败分布指向的是短时窗口还是长期超限，这决定了你是等一会儿还是改节奏。
