限流发生时,最该做的不是立刻重试,而是先把已经拿到的数据落盘、标记完整度,再决定后续请求怎么发。只要你的脚本把每次响应连同请求参数、时间戳和状态码一起写入本地存储,限流只会中断增量部分,不会让已有结果失效。下面以你手里的一份页面清单和一份抓取日志为对象,说明可执行的最小动作,以及哪些结论不能仅凭限流现象得出。
搜索引擎优化软件通常由三层组成:你维护的输入清单、脚本发出的请求、以及工具或接口返回的原始响应。限流一般作用在请求层,但很多人会把“请求失败”误当成“结果无效”。
因此,保护的重点是原始响应,而不是最终报表。如果你的脚本边请求边覆盖同一个结果文件,限流一来,新数据没拿到,旧数据也可能被写坏。改成追加写入或按批次分文件,是成本最低的改动。
假设你有一份 500 条 URL 的清单,脚本跑到第 180 条时开始收到限流响应。此时可执行的最小动作是:
batch-001.jsonl,每行包含请求参数、状态码、响应体摘要和抓取时间。pending.jsonl,只保留输入参数,不写空结果。这个动作的结果是:你得到了一份完整度可验证的检查点。下一步不是马上重跑全部 500 条,而是只对 pending.jsonl 中的条目安排重试。这样既减少请求量,也避免用重复请求再次触发限流。
需要说明的是,“已成功返回 179 条”只能证明这 179 条拿到了响应,不能证明这些响应在业务上都是有效数据。返回体可能包含空结果、错误页或被拦截的提示内容。判断有效性需要另一步:抽样检查状态码与响应体是否匹配预期结构。
限流的常见信号包括:连续多个请求返回同一类拒绝状态、响应时间明显拉长、返回体中出现频率限制提示。这些信号的具体表现因工具和接口而异,需要你核对实际返回内容,不能照搬某一种判断标准。
可执行的做法是给重试设置三个约束:
调整后如果请求恢复正常,说明之前的节奏超出了当前允许的调用频率;如果仍然被拒绝,就不能简单归因于“频率太高”,还可能是权限范围、调用配额或账号状态的问题。这两种原因对应的下一步不同:前者继续调低节奏,后者需要先确认权限和配额,再决定是否继续。
限流往往意味着你拿不到全量结果。此时不要用不完整数据去支撑全站结论,而是把交付范围缩小到已验证的部分。
假设你只成功抓取了 179 条 URL,其中抽样 30 条确认响应结构正常。可以交付的内容是:这 179 条的原始响应、抽样验证记录、以及未完成条目的清单。不能交付的内容是:基于 179 条推算全站问题的比例或趋势。因为未抓取的条目可能集中在某一类模板或某一批目录下,缺失并非随机。
一个明确假设的短例子:如果这 179 条全部来自文章页,而待抓取的 321 条包含商品页和分类页,那么即使文章页的标题长度分布很集中,也不能说明商品页同样如此。缺失部分的分布未知,任何外推都缺少依据。
限流结束后,值得保留的不是一次性重试脚本,而是一组保护规则:
这些规则的作用是让限流只影响增量,不影响存量。当你下次再遇到类似中断时,可以直接从检查点继续,而不是从头再跑一遍。至于具体工具的配额、权限和调用限制,需要以你实际使用的版本和账号状态为准去核对,不能沿用他人环境下的参数。