网站推广自动化工具：脚本被限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /baed23a1f6c1.html
📄
网站推广自动化工具：脚本被限流时怎样保护已有结果
先给结论：限流发生时，最该保护的往往不是“把这一轮跑完”，而是把已经拿到的有效结果固化下来，并让后续任务可以安全续跑。假设一个情境：你用网站推广自动化工具批量查询一批页面的收录与标题信息，前 80 条正常返回，第 81 条开始连续报错、返回空值或响应变慢。此时如果脚本继续按原速重试并覆盖原文件，很可能把前 80 条也写坏。正确动作是立即停止写入、切换到只读缓存、再决定是降速续跑还是分批重跑。
先判断是限流还是数据本身有问题
连续报错不等于一定被限流。可区分的证据有几类：如果错误集中出现在固定时间窗口、且间隔性恢复，更像限流；如果只有特定字段为空、其他字段正常，更像页面结构或查询参数问题；如果同一批数据换一个出口就正常，说明问题在调用侧而不是数据侧。先做一次小样本对照，比直接改脚本更省事。
假设情境里，第 81 条之后全部超时，但把其中 3 条单独放慢重试又能返回，这就支持限流判断。此时不要急着调大并发，而应记录三个量：已成功条数、首次失败位置、失败后的等待时长。这三个量决定下一步是续跑还是重跑。
保护已有结果的三个动作
第一个动作是写入与抓取分离。每成功一条就追加写入带时间戳的原始结果文件，而不是最后一次性覆盖。这样即使脚本中断，前 80 条仍在。第二个动作是给结果加状态标记，把每条标为成功、失败、待重试，避免把空值当成有效结果混入。第三个动作是保留原始响应，至少保留状态码和返回片段，方便事后判断是限流还是数据异常。
一个具体做法是用 append 模式写 JSON Lines，每行一条记录，字段包含查询值、返回内容、状态、时间。这样下一轮脚本可以从“待重试”列表继续，而不用重新跑全部数据。动作的结果是：限流只影响未完成部分，已完成部分不受影响，下一步的续跑范围也随之缩小。
续跑还是重跑：用条件区分
两种选择都成立，但适用条件不同。
- 续跑适合：成功结果字段完整、失败集中在尾部、失败原因是超时或明确限流提示。此时从失败位置继续，并降低并发或增加间隔。
- 重跑适合：成功结果里混入了空值或异常值、查询参数在失败后被修改过、或无法确认前 80 条是否用了同一口径。此时应整批重跑，但重跑前先备份旧结果。
判断依据不是失败条数多少，而是已成功结果是否可信。如果可信，续跑成本更低；如果不可信，续跑只会把错误延续下去。假设情境中前 80 条字段完整且时间戳连续，就可以续跑；如果发现其中几条标题为空但被标成成功，就应改为重跑并修正校验规则。
降速策略要能回退
限流后的降速不应是一次性写死。更稳妥的方式是把并发数、请求间隔、单批数量做成可调参数，并允许在连续失败时自动回退到上一档。例如从并发 5 降到 2，间隔从 1 秒增到 3 秒。每次调整后只跑一小批验证，确认稳定再扩大。
需要说明的是，不同工具对限流的处理方式不同，具体阈值、退避规则和是否支持断点续传需要核对实际使用的工具文档。不要照搬某个样本里的参数，因为样本量小的时候可能不触发限制，规模化后才会出现例外。
把保护动作变成固定流程
可执行的最小流程是：先备份已有结果文件；再读取待重试列表；用降速参数小批试跑；确认稳定后逐步扩大；每批结束后追加写入并更新状态。这样做的结果是，即使再次遇到限流，损失也只停留在当前小批，而不是整轮任务。下一步的判断依据也随之清晰：如果小批稳定，就继续扩大；如果仍失败，就回到只读模式，先排查调用侧原因，而不是继续消耗请求。
