关键词工具：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /345e9ad52337.html
📄
关键词工具：脚本调用工具遇到限流时怎样保护已有结果
限流发生时，先不要重试到把已有结果覆盖掉。更稳妥的顺序是：立即停止写入，把已经拿到的数据封存为只读快照，再根据你手里是否还有可用的请求配额，决定是继续增量拉取还是转为离线整理。这样即使后续请求全部失败，前面已经花掉配额换来的结果仍然可用。
先判断限流是临时拒绝还是配额耗尽
两种情况的处理方式不同，误判会导致你白白浪费剩余配额。
- 临时限流：通常表现为短时间内的请求被拒绝，但过一段时间可能恢复。特征是拒绝发生得很快、很密集，且没有明确的配额归零提示。
- 配额耗尽：表现为持续拒绝，且你已知当日或当周期的调用量接近上限。特征是拒绝稳定出现，不随等待时间改善。
区分依据不是单次报错文本，而是拒绝是否随时间缓解。可以设一个最小探测动作：等待一段固定时间后只发一个请求。如果这个请求成功，说明更接近临时限流；如果仍然失败，按配额耗尽处理，转入离线模式。
这里要提醒一个常见误判：请求量归零或抓取量突然下降，并不能单独证明限流已经解除，也可能是脚本自身出错、网络中断或目标端返回了空结果。需要结合脚本日志里的状态码和错误类型一起看。
保护已有结果的最小动作
不管哪种限流，第一步都是一样的：把当前结果写成不可变快照。具体动作可以是这样——
- 停止所有会覆盖原文件的写入操作，包括追加和去重合并。
- 把已获取的数据复制一份，文件名带时间戳，例如
keywords_20250101_1200.json，并设为只读。 - 记录这份快照对应的请求参数、页码或游标位置，写进一个单独的日志文件。
这个动作的结果会直接影响下一步：有了快照和游标位置，你才能在限流解除后从断点续拉，而不是从头再来；没有它，重试可能把不完整的数据当成完整结果使用。
有剩余配额时：降速续拉，不做并行重试
如果你判断还有少量可用配额，选择降速续拉比立即重试更划算。做法是把并发降到最低，请求之间加入固定间隔，并且只从快照记录的游标位置往后拉。
适用条件：你确认配额没有完全耗尽，且目标数据有明确的顺序或分页结构。此时每成功一次就追加写入快照的新副本，而不是修改原快照。
例外：如果数据本身没有稳定顺序，或者分页会随请求变化，那么断点续拉可能产生重复或遗漏。这种情况下更适合等限流完全解除后重新拉取，并把旧快照保留为对照，而不是强行续拉。
无剩余配额时：转为离线整理，不空等
如果确认配额已耗尽，继续发请求只会延长被封的时间。此时应把已有快照当作本轮的唯一产出，转入离线整理：
- 对快照内的数据做去重、字段校验和缺失标记，明确哪些字段是完整的、哪些是截断的。
- 把缺失部分单独列成待补清单，而不是用推测值填满。
- 如果后续还要调用同一工具，先把待补清单按优先级排序，等配额恢复后按清单拉取。
假设你的快照只覆盖了前 200 条结果，而完整列表可能有 500 条。此时可以基于这 200 条做初步判断，但必须标注样本范围和截断位置，不能把它当作全量结论使用。这是假设示例，用于说明标注范围的方法，不代表任何具体工具的实际返回规模。
重新调用前要确认的前提
在恢复请求之前，先核对三件事：配额是否真的恢复、脚本的写入逻辑是否已经改成追加而非覆盖、快照的游标位置是否准确。任何一项没确认就重跑，都可能让之前的结果失去参照价值。
另外，限流期间不要同时保留多个写入进程。多个脚本并发写同一份结果文件，是快照被破坏最常见的原因之一。把写入收敛到单一进程，是保护已有结果成本最低的一步。
