关键词筛选工具：脚本调用遇限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b34f9d8173b4.html
📄
关键词筛选工具：脚本调用遇限流时怎样保护已有结果
结论先说：如果限流发生在“批量请求—汇总”之间，优先做的是把已返回的每一条记录立即落盘并标记来源批次，而不是先重试。只要落盘动作发生在请求循环内部，限流最多让本轮变慢，不会让前面已拿到的结果作废；反过来，如果结果只存在内存或临时变量里，一次限流中断就可能让整批白跑。这个结论成立的前提是：工具返回的每条结果能对应到唯一标识（如关键词本身或请求参数组合），并且你允许同一标识被重复写入。若结果之间无法区分来源、或后续步骤依赖“全量齐全才能计算”，那么单条落盘只保住数据、保不住结论，需要换一种处理顺序。
先分清限流是“拒绝”还是“降速”，两者保护动作不同
很多脚本把限流当成同一个错误处理，结果要么过度重试、要么直接放弃。实际至少有两类表现，证据不同，动作也应不同：
- 请求被直接拒绝：返回明确的错误状态或空响应，且连续多次都如此。这通常说明触发了频次或配额上限，继续原速重试只会加深问题。
- 响应变慢但仍有数据返回：单次等待时间明显拉长，但结果结构正常。这更像服务端在主动降速，此时把并发降下来往往比停止更划算。
区分方法很直接：记录每次请求的时间戳、返回状态和结果条数。如果错误集中在某个时间窗口之后，偏向拒绝；如果时间戳均匀拉长、错误零星出现，偏向降速。这一步的意义在于决定下一步是“退避后继续”还是“缩小批量后继续”，而不是无差别地加长等待。
落盘要带批次标记，否则恢复时无法判断哪些能信
只把结果写进一个文件还不够。限流中断后重新跑，最怕的是分不清哪些记录来自完整批次、哪些来自被打断的批次。建议每条记录至少带上三个字段：唯一标识、请求参数、写入时间或批次号。这样恢复时可以按批次取舍，而不是整文件重跑。
一个假设的例子：假设你用脚本按关键词列表逐个调用工具，列表有若干条。第一轮跑到中途被限流，此时已写入的记录都带批次号 A。恢复时你不清空文件，而是以批次号 B 继续写，最后按标识去重、保留最新一条。这样即使 B 批次再次中断，A 批次的数据仍然可用。这里的关键动作是“继续追加并去重”，它直接影响下一步：你不必等全量跑完才能开始核对，可以先对已有部分做抽样检查。
什么时候“保住已有结果”这个思路会失效
反例出现在结果之间存在依赖关系时。比如某些筛选逻辑需要先拿到全部候选，再统一计算相对排序或占比。这种情况下，部分结果虽然被保存下来，但单独看没有意义，因为排序会随缺失项变化。此时正确的保护对象不是“每条结果”，而是“已完成的处理阶段”。做法是把阶段边界写进状态文件：哪些标识已请求、哪些已归一化、哪些已参与计算。中断后从阶段边界恢复，而不是从结果文件恢复。
判断自己属于哪种情况，可以问一句：删掉任意一条已保存的记录，剩下的结论会不会变？会变，说明结果之间有依赖，应保护阶段；不会变，说明结果相互独立，逐条落盘就够。
恢复时先做一次小批量验证，再决定是否放大
限流缓解后直接按原并发全速重跑，风险是再次触发限流，把刚恢复的进度又打断。更稳的动作是先跑一个明显更小的批量，观察返回状态和耗时是否回到正常区间。如果小批量稳定，再逐步放大；如果小批量仍被拒绝，说明限制条件可能不只是频次，继续加等待未必有效，需要核对工具方对调用方式的说明。
这里要说明一个容易误判的点：请求量或抓取量归零，并不能单独证明你的保护逻辑正确。它也可能是列表本身已跑完、参数写错导致没有请求发出、或工具返回结构变化使脚本无法识别。所以每次恢复后，除了看数量，还要抽查几条记录的内容是否完整、字段是否对得上。只有内容和数量同时正常，才能把这次恢复视为有效。
把保护动作固定成三步，减少下次中断的损失
- 请求循环内即时写入：每拿到一条就写，不攒批。写入内容包含唯一标识、请求参数、批次标记。
- 恢复时追加而非覆盖：以新批次号继续写，最后按标识去重，保留最新或最完整的一条。
- 先小批量再放大：用一次小规模调用确认限制已缓解，再回到正常并发，避免二次中断。
这三步不解决限流本身，它们解决的是限流发生后的损失范围。至于具体工具当前的调用上限、退避策略和返回字段含义，不同实现差异较大，需要以你所用工具的现行说明为准，不要照搬别处的参数。做完这三步后，下一步该做的是核对已保存记录的内容质量，而不是急着补全剩余部分——因为如果字段本身对不上，补得越多，返工越大。
