关键词采集工具脚本调用遇限流，怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b50931402cc3.html
📄
关键词采集工具脚本调用遇限流，怎样保护已有结果
先给结论：脚本被限流时，不要立刻重跑，而是先把已经拿到的数据落盘封存，再判断限流是配额型还是风控型。配额型限流通常等待后恢复，风控型限流则需要降低频率或更换调用方式，两者的处置动作不同，混在一起处理容易把已有结果也弄丢。
一个矛盾现象：限流后重跑，结果反而更少
很多脚本在收到限流响应后，会走同一条重试逻辑：等待固定秒数，重新发起整批请求。矛盾就在这里——第一次运行可能已经拿到七成数据，重跑之后因为触发更严格的限制，只拿到三成，而且覆盖了原来的文件。表面看是"限流变严重了"，实际上是脚本把已有成果当成了可丢弃的中间态。
另一个常见现象是结果数量归零。这不能单独证明限流处理正确，也不能证明源站删了数据。归零还可能来自：本地写入被重试逻辑清空、分页游标被重置到起点、请求头或鉴权在重试时丢失。把归零直接当成"数据没了"是最容易误判的一步。
两种解释：配额耗尽与行为触发
解释一：配额型限流
这类限制来自账号或密钥的调用额度、单位时间请求数上限。特征是：限流响应里往往带有剩余额度、重置时间等字段；同一密钥换个时间窗口调用就能恢复；不同密钥之间互不影响。如果工具是按账号计费的，这种限流更常见。
解释二：风控型限流
这类限制来自请求特征本身：频率过高、间隔过于均匀、请求头不完整、来源 IP 集中。特征是：即使额度没满也会被拦；换密钥不一定有效；放慢速度后恢复，但一提速又立刻被拦。它针对的是行为模式，不是剩余配额。
能区分两种解释的证据
- 看响应内容。带明确额度字段和重置时间的，偏向配额型；只返回通用拒绝状态、无额度信息的，偏向风控型。
- 做对照调用。用同一密钥在明显更慢的节奏下试几个请求。能通，说明是频率或行为问题；仍然不通，且响应指向额度，说明是配额问题。
- 换维度验证。换一个来源出口或换一个密钥再试。只有换出口才通，偏向风控型；只有换密钥才通，偏向配额型。
- 看失败分布。在请求序列中均匀出现失败，偏向配额型；集中在某个时间点之后连续失败，偏向风控型。
这些证据只能缩小范围，不能单独定论。比如换出口后恢复，也可能是那个出口的线路质量更好，而不是风控解除。
保护已有结果的最小动作
无论属于哪种限流，第一步动作都一样：在发起任何重试之前，把当前结果以追加方式写入独立文件，并记录本次运行的请求参数、时间戳和已成功获取的范围。
具体可以这样做：
- 把结果写入带运行标识的文件，例如
result_run_01.jsonl，每行一条，写完即刷盘。 - 单独维护一个进度文件，记录已成功的分页游标或偏移量。
- 重试逻辑只从进度文件记录的断点继续，绝不从头覆盖。
- 限流发生时，先写一条包含响应状态和时间的日志，再决定是否重试。
这个动作的结果会直接影响下一步：如果断点和结果都完整保留，你可以放心地在等待后做增量续跑；如果发现结果文件被覆盖或进度丢失，那么当务之急是修脚本的写入逻辑，而不是继续调请求频率。很多"限流后数据对不上"的问题，根源在写入策略，不在限流本身。
判断能否继续，以及不能推出什么
一个简化的假设例子：某次运行计划请求 100 页，成功 62 页后开始连续失败。若失败集中出现在第 63 页之后且响应无额度信息，先按风控型处理，把间隔拉长、减少并发，从第 63 页续跑；若响应明确显示额度用尽并给出重置时间，则按配额型处理，等到重置时间后再从第 63 页续跑。两种情况下，前 62 页的结果都应原样保留，不参与任何重写。
需要明确的适用条件：上述判断依赖你能拿到响应内容和进度状态。如果脚本只返回成功或失败、不保留响应体，也不记录断点，那么你缺少区分两种解释的证据，此时能执行的最小动作只剩"停止重跑、保存现有输出、人工检查文件是否完整"。在这种情况下，不能推出限流类型，也不能推出剩余数据能否补齐。
最后要避免一个推论：某次限流后请求量下降或结果变少，不能单独证明你的降速策略生效，也不能证明源站收紧了限制。请求量下降可能只是脚本提前退出了循环，结果变少可能只是写入被覆盖。把现象和原因分开，先保住已有结果，再谈恢复采集。
