关键词添加工具，脚本调用被限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /02b4d256b56d.html
📄
关键词添加工具，脚本调用被限流时怎样保护已有结果
先给结论：不要在被限流后继续重试同一批请求，而是立刻把已经拿到的结果落盘并标记批次状态，再用“未完成清单”决定下一步。限流本身不是数据损坏，真正危险的是内存里的结果随进程退出而丢失，或者重试逻辑把已成功的结果覆盖成失败记录。
假设情境：一次批量调用中途收到限流响应
假设你有一个脚本，通过某类关键词添加工具的接口批量补充词条属性。前 200 条正常返回，第 201 条开始连续收到限流响应。此时脚本如果直接抛出异常退出，前 200 条结果只存在内存里，就全部作废；如果脚本无脑重试，可能让限流窗口延长，还会把已经成功的记录重复写入。下面把决策拆成落盘、判定、续跑三步。
第一步：限流发生瞬间先落盘，再决定是否停止
收到限流响应的第一动作不是判断原因，而是持久化。把已完成结果写入本地文件或数据库，同时记录三个字段：批次标识、每条记录的处理状态、最后成功的位置。状态至少区分“成功”“失败”“未处理”，不要只存一个成功列表，否则续跑时无法知道哪些是漏掉的。
一个实际动作是：在每次写入成功后立即追加一行带时间戳的记录，而不是等整批结束再统一保存。这样即使进程被强制终止，已落盘部分仍然可用。这个动作的结果会直接影响下一步——如果落盘完整，你可以放心停脚本；如果发现落盘只到第 150 条，就要先补写内存中剩余的 50 条，再谈重试。
适用条件：结果可重复获取、单条记录不大时，边跑边落盘成本很低。如果单条结果很大或写入本身很慢，可以按固定条数分批落盘，但批次大小要小于你预计的限流触发阈值。
第二步：区分限流的两种性质，决定等待还是换策略
限流响应本身信息有限，但可以从时间分布区分两类情况。一类是短窗口限流：停止请求后几十秒到几分钟内恢复，继续按原节奏调用仍会再次触发。另一类是配额耗尽：当天或当周期的额度已经用完，继续等待没有意义。
- 短窗口限流的证据：间隔一段时间后单条试探请求成功，且连续少量请求不再被拒。
- 配额耗尽的证据：长时间等待后试探请求仍被拒，或响应中带有明确的周期重置提示。
这两类情况对应不同决策：短窗口限流可以降低并发、加入间隔后续跑；配额耗尽则应停止当天任务，把未完成清单留到下一个周期。注意，请求量归零或抓取量下降不能单独证明限流已经解除，也可能是脚本自身出错或目标端返回了其他错误，需要先用一条试探请求确认。
第三步：用未完成清单续跑，避免覆盖已有结果
续跑前先根据落盘状态生成未完成清单：状态为“失败”和“未处理”的记录进入重试队列，“成功”记录跳过。写入时使用幂等键，例如词条本身的唯一标识，确保同一记录重复处理不会产生两条结果。
假设前 200 条成功、第 201 到 260 条失败、第 261 条之后未处理。正确的续跑范围是 201 到 260 加 261 之后，而不是从第 1 条重跑。如果从第 1 条重跑，除了浪费配额，还可能因为工具返回的字段顺序或时间戳变化，让原本正确的记录被新结果覆盖。这个动作的结果是：续跑批次更小，再次触发限流的概率下降，同时已有结果保持稳定。
需要提前定好的两个取舍
取舍一：实时落盘还是批量落盘。实时落盘保护更完整，但写入次数多；批量落盘写入少，但崩溃时可能丢失最后一批。选择依据是单条结果能否快速重新获取——能快速重取就批量落盘，不能就实时落盘。
取舍二：自动重试还是人工确认后续跑。自动重试适合短窗口限流且重试次数有上限；一旦出现配额耗尽迹象，自动重试只会消耗更多额度，此时应改为人工确认周期重置后再启动。判断标准是试探请求是否成功，而不是已经等待了多久。
最后提醒一点：不同关键词添加工具对限流的定义、响应格式和配额周期并不相同，具体阈值和重置规则需要以你所用工具的当前说明为准，不要照搬其他脚本的参数。把落盘、状态标记和未完成清单这三件事固定成脚本的默认行为，限流就只是一次中断，而不是一次数据损失。
