网站工具：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bb67e8d7deec.html
📄
网站工具：脚本调用工具遇到限流时怎样保护已有结果
保护已有结果的关键不是“重试到成功”，而是把每次调用变成可落盘、可续跑、可对账的批次：先冻结已经拿到的原始响应，再按限流信号缩小并发和批量，最后用断点清单决定哪些条目补跑、哪些条目必须放弃或改走人工。下面以你手里的一份待处理清单为例，说明怎么落地。
先冻结原始响应，再谈重试
限流发生时，最危险的动作是继续覆盖同一个结果文件。脚本一旦把空响应、错误页或截断内容写进正式结果，后续很难区分“本来没有数据”和“这次被限流了”。
可执行的处理顺序是：
- 为每个请求单独保存原始响应体、时间戳、请求参数和状态码，文件名用稳定标识，不用递增序号。
- 正式结果文件只由“已确认成功”的原始响应生成，不直接承接脚本的即时输出。
- 把限流相关的状态码、错误文案和空响应统一标记为“未完成”，而不是“无数据”。
做完这一步，你的下一步才有依据：如果原始响应完整，就可以离线重新解析，不必再次请求；如果原始响应本身是限流页，就必须重新排队。这个区分决定了后面是“省调用”还是“补调用”。
用限流信号决定降速方式，而不是凭感觉
不同工具给出的限流信号不一样，常见的有明确的状态码、响应头里的剩余额度提示、返回体中的错误说明，或者干脆表现为连接被拒、响应变慢。先确认你面对的是哪一种，再选择降速策略。
- 有明确额度和重置时间：把清单切成批次，每批控制在额度以内，批次之间留出重置窗口，不要用固定睡眠时间硬扛。
- 只有错误码、没有额度信息：采用指数退避，并给单条记录设置最大尝试次数。达到上限就转入“待人工”清单，不无限重试。
- 表现为整体变慢或连接失败：先降并发，再降频率。并发从 4 降到 2、再降到 1，比直接停掉整个任务更容易判断瓶颈在哪。
这里要避免一个常见误判：某次重试成功了，不代表限流已经解除，可能只是恰好落在额度恢复的瞬间。判断是否恢复，要看连续多个请求的稳定表现，而不是单次结果。
把清单拆成三种状态，断点续跑才可控
规模化之后出现例外，通常是因为清单里混着不同性质的条目。建议在任务开始前就给每条记录一个状态字段，至少分成三类：
- 已完成：原始响应完整且校验通过。续跑时直接跳过，不再请求。
- 可重试：确认是限流导致失败，参数没问题，等待窗口后重跑即可。
- 需人工：重试达到上限、返回内容与预期结构不符，或该条目本身可能触发额外限制。
假设你的清单有 500 条，前 80 条正常完成，第 81 条开始连续返回限流错误。此时正确动作是停止新增请求，把 81 到 500 标记为“未处理”，检查第 81 条是否属于特殊类型。如果它只是普通条目，说明是整体额度问题；如果它带有特殊参数，说明是条目级限制，那就应该把它单独隔离，继续处理后面的普通条目，而不是整批停摆。这个判断直接影响你是“等额度”还是“改清单”。
重试前先做一次可对账的抽样
限流期间拿到的结果，质量往往不均匀。恢复调用前，从已完成部分抽一小批做对账：用同一参数再请求一次，比较两次的字段是否一致。如果一致，说明之前的原始响应可信，可以继续按原方案推进；如果出现字段缺失或结构变化，说明限流期间可能返回了降级内容，需要重新评估已完成部分的可用范围。
抽样规模不需要大，但要覆盖不同类型的条目，尤其是参数最复杂的那几条。对账结果决定三件事：已完成部分是否直接采用、可重试部分是否要调整参数、以及是否需要为高风险条目单独设置更慢的调用节奏。
把保护动作写进脚本的退出逻辑
真正能保护已有结果的，是脚本在异常退出时留下的现场，而不是事后回忆。至少要让脚本做到：
- 每完成一条就落盘一次状态，而不是全部跑完再统一写入。
- 收到限流信号后先保存当前进度，再退出，不继续消耗额度。
- 退出时输出一份摘要：成功多少、可重试多少、需人工多少，以及最后一次成功的位置。
这样下次启动时，你只需要读取状态文件，从断点继续，而不是从头再跑一遍。对已有结果的保护，本质上就是把“这次跑到哪、哪些能用、哪些不能碰”变成文件里的确定信息。做到这一点，限流只会拖慢进度，不会毁掉已经拿到的数据。
