📍 WDQWDWQD987AAAAA:216.73.216.103
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6c5d0c85b4b8.html
📄

关键词查询工具：脚本调用遇到限流时怎样保护已有结果

限流发生时，最该保护的不是“下一次请求”，而是已经拿到的结果和已经花掉的调用额度。可行做法是：把每条结果立即落盘、记录它对应的请求参数与分页位置，并把限流响应单独存档；之后只重试未完成的部分，而不是从头再跑一遍。这样做的直接结果是，你能明确知道哪些数据可继续使用、哪些区间必须补齐。但要注意，落盘成功不等于数据完整，也不等于限流已经解除。

先分清两种限流解释，再决定要不要重跑

脚本被限流后，常见的第一反应是“工具封了我”，于是换代理、换账号、加长休眠，甚至整批重跑。但同样的限流现象至少有两种解释，处理方式完全不同。

• 解释一：请求节奏超过服务端允许的速率。特征是限流集中出现在短时间密集调用之后，间隔拉长后能恢复，且恢复后返回的数据与之前同参数的结果一致。
• 解释二：当前凭据、配额或权限本身已不足以支撑这类调用。特征是无论怎么放慢节奏都持续被拒，或者部分接口可用、部分接口稳定失败，返回信息指向配额或权限而非频率。

能区分这两种解释的证据是：把同一批请求按明显更低的频率重放一小段，观察是否恢复。若恢复，倾向节奏问题；若在低频下仍稳定失败，倾向配额或权限问题。这一步只需要少量请求，不必整批重试。

已有结果要落成可续跑的结构，而不是一堆散文件

保护已有结果的关键，是让每条记录都能回答三个问题：它由什么参数产生、它属于哪一页或哪个区间、它是否完整。只把返回内容写进一个大 JSON 或一张大表，后续很难判断缺口在哪。

假设一个场景：脚本按关键词逐页抓取，每页返回若干条。跑到中途被限流。此时如果只保存了“所有已返回条目”，你无法知道第 7 页是完整返回还是只返回了一半。更稳妥的做法是逐页保存，并在每条记录旁写入页码、请求参数和抓取时间，例如：

{"page": 7, "params": {"q": "example"}, "items": [...], "complete": false}

其中 complete 字段由脚本根据返回结构判断，而不是凭感觉填写。这样做的结果是，恢复运行时可以从第一个 complete: false 的位置继续，而不必重跑前面已完整的页。假设每页成本相同，只补缺口通常比整批重跑消耗更少调用次数，但这个比较依赖你的分页方式和限流规则，不能直接当成结论。

限流响应本身也要存档，它是判断下一步的依据

很多人只保存成功结果，把限流返回丢掉，导致事后无法判断当时是频率问题还是权限问题。限流响应中的状态码、提示文本、响应头里的重试相关字段，往往比成功数据更能决定下一步动作。

建议把失败响应按时间顺序单独记录，至少包含：触发时的请求参数、连续失败次数、两次失败之间的间隔。这样你能看出失败是随调用密度上升而出现的，还是从一开始就存在。前者支持“降速后继续”，后者支持“先核对凭据与配额，再决定是否继续”。

需要说明的是，请求量下降或某段时间返回为零，并不能单独证明限流已解除。它也可能只是当前区间本来就没有数据，或参数写错导致空结果。要区分这两种情况，可以先用一个已知有结果的参数做小样本验证，再恢复正式抓取。

缺少完整数据或权限时，仍可执行的最小动作

如果你既拿不到完整配额，也没有更高权限，仍有一组不依赖额外授权的最小动作：

1. 停止所有并发请求，把并发降到单线程或最小间隔。
2. 对已有结果做一次完整性标记，列出所有 complete: false 的区间。
3. 只对缺口区间发起少量试探请求，验证限流是否缓解。
4. 把试探结果与已有结果按同一参数对齐，确认没有重复或错位。

这些动作的结果是：你能得到一份“已知完整区间 + 已知缺口区间”的清单。它的价值在于让后续任何补齐动作都有明确边界。但必须明确，这份清单不能推出“数据已经全量”或“工具不会再限流”。它只说明当前掌握的部分是否可用。

如果试探请求仍然持续失败，且失败信息指向权限或配额，那么继续降速通常没有意义，此时应把已有结果冻结、标注缺口，而不是反复重试消耗剩余额度。

恢复抓取前，先做一次小样本对齐

限流缓解后，不要直接全量续跑。先用少量请求验证三件事：返回结构是否与限流前一致、同参数结果是否稳定、分页边界是否仍然对齐。假设限流前第 7 页返回 10 条，恢复后同参数第 7 页返回 8 条，那就说明分页逻辑或数据源已经变化，此时按页码续跑会产生错位。

一旦发现结构或数量不一致，正确动作是回到“按参数对齐”而不是“按页码对齐”，必要时重新界定缺口区间。这个判断会直接影响你后续要补多少数据，也决定已有结果中哪些部分需要重新核验。整个过程不需要完整权限，但需要你保留足够的过程记录，否则无法做这种对齐。