网站安全查询，脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4ef4c2a45313.html
📄
网站安全查询，脚本调用工具遇到限流时怎样保护已有结果
限流发生时，已经返回的那部分结果通常还在内存里，但脚本往往因为异常退出而把它们一起丢掉。保护已有结果的关键不是绕过限流，而是让脚本在收到限流信号后先落盘、再决定是否重试。下面从两种常见解释入手，说明怎样判断你遇到的是哪一种，以及对应该做什么。
限流后结果丢失，通常是两种原因之一
第一种是接口返回了明确的限流状态，脚本把它当成普通错误抛出，进程退出，内存中的列表随之消失。第二种是接口没有明确报错，只是响应变慢或返回空数据，脚本继续循环，把空结果当成有效结果写入，最终覆盖掉之前已经拿到的内容。
这两种情况的处理方式完全不同。前者需要捕获异常并保存，后者需要识别“空响应不等于无风险”并停止写入。如果你只是笼统地加重试，第二种情况反而会让错误数据越积越多。
用三个证据区分你遇到的是哪一种
- 看日志里有没有明确的状态码或错误关键字。有，偏向第一种；没有，偏向第二种。
- 看失败前后的结果数量变化。失败前已有 N 条，失败后变成 0 或明显减少，说明写入被覆盖，偏向第二种。
- 看限流是否集中在固定时间窗口。集中在某几分钟，偏向第一种的服务端节流；随机分散且伴随超时，偏向第二种。
这里要提醒一点：请求量突然归零或抓取量下降，并不能单独证明限流就是唯一原因。网络中断、目标站点临时维护、脚本自身超时设置过短，都会产生类似现象。所以判断时要结合日志时间戳和错误类型，而不是只看数量。
让脚本先落盘再重试的实际动作
假设你有一个循环，每次调用工具拿到一批结果，追加到一个列表里。可以改成每处理完一批就写入一次本地文件，而不是等全部跑完再写。写入时用追加模式，并给每条记录带上时间戳和批次号。
具体动作是：在调用工具的那一行外面包一层异常捕获，捕获到限流相关错误时，先把当前列表写入文件，然后记录断点位置，再决定是等待后重试还是退出。这样即使脚本中途停止，下次运行时可以从断点继续，而不是从头再来。
这个动作的结果是：你不再依赖“一次跑完”这个假设。限流从“全盘失败”变成“暂停”，已有结果保留下来，下一步只需要处理剩余部分。如果重试多次仍然失败，你也可以拿着已落盘的结果先做分析，而不是空手等待。
一个注明假设的短例子
假设某个查询脚本需要处理 200 个目标，每批 10 个。跑到第 8 批时接口开始限流。如果脚本在每批结束后追加写入文件，那么第 7 批的 70 条结果已经安全。此时捕获异常并退出，下次从第 8 批继续即可。如果脚本是全部跑完才写，这 70 条也会丢失。这个例子里的数字只是用来对比两种写入时机的差别，不代表任何真实工具的处理速度或限额。
需要说明的是，不同工具对限流的判定方式和恢复时间各不相同，具体阈值和等待策略需要以你所用工具的当前说明为准，不能照搬其他服务的参数。
落盘之后还要检查的一件事
结果保住了，不代表可以直接用。限流期间返回的数据可能不完整，比如某个字段为空、某条记录只返回了部分信息。建议在落盘时给每条记录标记来源批次，后续分析时先过滤掉明显不完整的记录，再决定是否需要补查。
如果补查成本高，可以先对已有结果做一次去重和字段完整性检查，确认哪些目标确实缺失，再针对缺失部分重新调用。这样既保护了已有结果，也避免了对已经拿到的数据重复请求，减少再次触发限流的可能。
最终判断标准很简单：脚本停止后，你手里是否还有可用的数据。如果有，限流只是流程问题；如果没有，才需要回头检查写入时机和异常处理逻辑。
