搜索量查询，脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b6da1dbd8873.html
📄
搜索量查询，脚本调用工具遇到限流时怎样保护已有结果
遇到限流时，先别让脚本重试到底。把已经拿到的查询结果落盘、去重并标记覆盖范围，再让重试只补缺口，这样限流最多拖慢进度，不会把已有结果冲掉或混入重复数据。
先确认限流发生在哪一层，结果才算“已有”
限流可能来自接口返回的明确错误码，也可能表现为连接被拒、响应变慢或返回空数据。这几种现象不能一概而论：错误码通常说明请求节奏触发了限制；空数据既可能是限流，也可能是该查询本身没有返回结果；连接被拒还可能指向网络或代理问题。判断依据要落在可核对的证据上，比如响应状态、错误文本、时间戳和请求参数，而不是凭“这次跑得慢”就断定被限流。
对搜索量查询来说，一条结果至少应包含查询词、地区、时间口径、数据来源和抓取时刻。缺少其中任何一项，后续都很难判断缺口该不该补。假设你手头有一份 JSON 结果文件，先检查它是否记录了这些字段；如果只存了数值，限流后重跑时你无法区分“旧值属于哪个口径”，保护就无从谈起。
把已有结果写成不可变快照，再单独维护进度
保护已有结果的核心动作是分离“数据”和“进度”。数据文件一旦写入就不再改动，进度文件只记录哪些查询已完成、完成于什么时间、用的什么参数。这样重试时读取进度，跳过已完成项，只请求缺失项。
一个可执行的顺序是：
- 每完成一批请求，先把结果追加写入带时间戳的文件，并立即落盘。
- 按查询词、地区、时间口径生成唯一键，写入前做去重。
- 在进度文件中记录已完成的键和对应的结果文件位置。
- 遇到限流后停止当前批次，不覆盖任何已写入文件。
- 恢复时先读进度，再决定从哪个键继续。
这里的关键取舍是：宁可多写几个小文件，也不要在内存里攒到最后一次性写。进程被中断时，内存里的结果会一起丢失；已落盘的小文件则仍然可用。代价是文件数量变多，但换来的是限流和崩溃都不会让整批结果归零。
重试要限定范围，不能重新跑全量
限流恢复后最常见的错误做法是“从头再跑一遍”。如果新结果覆盖旧文件，你会失去限流发生前那段时间的原始记录；如果新旧结果混在同一文件里，重复键会让后续统计失真。更稳妥的做法是让重试只针对进度文件中缺失的键，并把新结果写入新的批次文件，而不是改写旧文件。
重试节奏也需要约束。可以给请求之间加入固定间隔，或在连续收到限流信号后逐步拉长等待时间。具体间隔取决于工具本身的限制说明，需要核对对应服务的当前文档，不能照搬别处的数值。判断重试是否有效的证据，是缺失键的数量是否在下降、错误率是否回落，而不是“感觉这次跑通了”。
假设一批查询共 200 个键，限流前完成了 120 个。恢复后如果只补剩余 80 个，并且新旧文件都保留，那么最终结果由 120 加 80 组成，任何一段都能单独追溯。如果重跑全量并覆盖，最终虽然也是 200 个键，但限流前的原始响应已经不可复原，一旦发现某个口径写错，你无法判断错误是何时引入的。
用可核对的证据区分“限流”和“没有数据”
当一批查询里出现大量空结果时，不要立刻归因于限流。合理的其他解释包括：查询词本身过于冷门、地区或时间口径设置过窄、参数拼写有误、返回结构变化导致解析失败。区分方法是保留原始响应，而不是只保留解析后的数值。原始响应里如果带有明确的错误信息，就偏向限流或参数问题；如果响应完整但字段为空，更可能是该查询确实没有数据。
另一个容易被忽略的点是：请求量下降或某次抓取返回零条，并不能单独证明限流处理正确。它也可能只是那批查询恰好没有结果，或者脚本提前退出了。要确认处理是否有效，应同时看错误类型、缺失键数量和进度文件的推进情况，三者一致时才更有把握。
把保护动作固化成下次可直接执行的规则
一次限流处理完后，值得把当时有效的规则写进脚本，而不是靠记忆。至少包括：结果文件按批次命名、进度文件独立维护、重试只补缺失键、原始响应与解析结果分开保存。这样下次再遇到限流，你不需要重新判断该保什么、该丢什么。
如果工具本身提供断点或缓存机制，需要先核对该工具的当前说明，确认它保存的是原始响应还是解析后的结果、是否按参数区分。不同工具的行为不一样，不能默认它一定保住了你需要的那一层。对搜索量查询而言，能追溯口径和抓取时刻的记录，比一个孤立的数字更有用。
