手机端SEO工具：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a18213449cbf.html
📄
手机端SEO工具：脚本调用工具遇到限流时怎样保护已有结果
先保住已经拿到的数据，再决定要不要继续跑。限流发生时最危险的动作不是停，而是让脚本带着半截状态反复重试，把已完成的分页、已写入的行覆盖掉。判断标准很简单：这批结果能不能在不重新请求的前提下独立成立。能，就转入本地续跑；不能，就只保留可验证的部分，其余标记为待补。
先区分限流：是配额到顶还是请求过快
两种限流的处理方向完全不同，误判会让保护动作白做。配额到顶通常表现为当天或当周期内所有接口一起失败，间隔多久重试都一样；请求过快则表现为部分成功、部分返回限流码，放慢节奏后能恢复。
- 配额到顶的证据：同一凭据下不同端点同时失败，且失败时间集中在一个窗口起点之后。
- 请求过快的证据：降低并发或拉长间隔后，同样的请求开始零星成功。
- 无法区分的合理解释：服务端临时抖动、凭据被其他任务共用、网络出口变化，都会造成类似现象，不能只凭一次失败下结论。
确认属于配额到顶，当天继续调用的期望收益接近零，应直接进入保留流程；确认属于请求过快，可以在保护结果的前提下改写调用节奏。
保留：把已完成结果落成不可回退的本地状态
保护已有结果的核心动作是让每次成功写入都带一个可判断完成度的标记。假设脚本按关键词分批抓取，每批返回若干条记录，那么每条记录至少要有三个字段：批次标识、抓取时间、该批次内的序号。这样即使后续调用全部失败，也能知道哪些批次是完整的、哪些是断的。
具体动作：在写入前先写一个批次占位记录，成功返回后把它改成完成状态。脚本重启时只处理未完成批次。这个动作的结果是，限流期间重启不会重复请求已完成批次，也不会因为覆盖写导致旧数据丢失。如果工具本身不提供状态字段，就在本地维护一份批次清单，用文件或轻量数据库记录，不要依赖内存变量——进程一退，内存里的进度就没了。
需要提醒的是，不同工具的返回结构、字段名和分页方式并不一致，具体以你所用工具的当前文档为准，不要照搬其他工具的参数名。
改写：只有在限流可恢复时才值得调整节奏
改写调用方式适用于请求过快这一类，前提是你已经确认放慢后能恢复。可调整的方向包括降低并发数、在批次之间加入等待、把一次大请求拆成多次小请求。
判断改写是否值得，看两个条件：一是剩余待抓量是否还大，二是单次请求的成本是否可控。如果只剩少量批次，直接等下一个周期比改写更省事；如果剩余量大且周期还长，改写才有意义。
改写时必须保留原有的批次状态文件，不要为了“跑得更快”清空进度重来。一个常见的错误是改并发的同时换了输出文件名，结果新旧两份数据对不上，反而要人工比对。保持输出路径和状态文件不变，只改调用参数。
退出：什么时候应该停止当天任务
以下情况建议直接退出，不做任何重试：凭据被明确告知已用尽、失败原因指向账号级别限制、连续多次重试后成功率为零且没有任何部分成功。
退出的动作不是删脚本，而是把当前状态冻结：记录最后一次成功的时间点、已完成批次范围、未完成批次清单。这份记录决定了下一步——如果是配额周期问题，下一个周期从断点继续；如果失败原因不明，先人工核对少量请求再决定是否恢复，而不是让脚本自动重跑。
一个需要避免的判断：把请求量归零当成“工具已经不可用”的证据。请求量归零也可能只是脚本提前退出、调度没触发、或状态文件被清空，这些都与工具本身无关。
恢复调用前的检查顺序
- 确认限流类型是否已经变化，配额是否进入新周期。
- 核对本地状态文件与已落库数据是否一致，重点看有没有“标记完成但实际为空”的批次。
- 先用一个最小批次试跑，确认返回正常再放开并发。
- 试跑成功后，只从未完成批次继续，不重跑已完成部分。
这套顺序的价值在于，每一步的结论都会影响下一步：如果试跑仍失败，就回到退出状态继续等待；如果试跑成功但状态文件对不上，就先修状态再放量。保护已有结果的本质，是让失败只影响未完成的部分，而不是把已经拿到的数据一起拖下水。
