百度司南工具脚本调用遇限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /203f901912e7.html
📄
百度司南工具脚本调用遇限流时怎样保护已有结果
结论先行：如果你已经把百度司南工具的结果落盘成可恢复的中间文件，限流只是节奏问题，继续按退避策略补齐剩余批次即可；如果你仍在内存里拼接结果、失败就整批重跑，那么限流会直接威胁已有产出，此时应先停止调用，把已拿到的部分固化成可续跑的快照，再决定是否恢复。判断依据不是报错本身，而是你的结果是否具备“分片可标识、写入可去重、进度可定位”这三个条件。
先判断你属于哪种调用形态
限流发生时，真正决定损失大小的不是限流强度，而是结果的组织方式。可以按下面两类对照自己的脚本：
- 可续跑形态：每个查询单元有稳定标识（如关键词加时间窗、条件组合的哈希），结果逐条写入独立文件或带唯一键的存储，脚本能记录“哪些单元已完成”。这类脚本遇到限流，最坏情况只是延迟，不会丢已有结果。
- 整批形态：所有结果先放进一个列表，循环结束后统一写文件或统一入库，中途异常就丢弃。这类脚本一旦被限流打断，前面已消耗的调用额度对应的数据可能全部作废。
如果你的脚本属于第二种，下一步动作不是调大重试次数，而是先改造写入方式：把“先攒后写”改成“逐条落盘并记录进度”。这个动作的直接结果是，之后任何一次限流都只会影响当前未完成的那一条，而不是整批。
限流当下应该先做的三件事
顺序很重要，先保护结果，再处理请求。
- 立即停止新请求，不要并发加码。很多脚本在收到限流信号后会启动多线程重试，这通常会让限流窗口延长。先让请求停下来，已有结果才不会继续被消耗。
- 把内存中未落盘的部分强制写出。哪怕格式不完整，也先写成一个带时间戳的临时快照文件。这一步的价值在于：即使后续重跑，你也能对比两次结果，而不是从零开始。
- 记录断点位置。明确最后一个成功写入的查询单元标识，以及它是成功返回、部分返回还是超时。断点信息决定了恢复时从哪里开始，而不是靠猜。
做完这三步，再去看限流的具体表现：是固定时间窗口内次数超限，还是并发数超限。两者对应的恢复策略不同——前者靠拉长间隔，后者靠降低并发。如果没有区分就统一加长等待，可能既慢又没有解决问题。
恢复调用时怎样避免二次损失
恢复阶段的核心原则是：让每次重试都可对账。
- 用唯一键去重。写入时以查询单元标识作为键，重复写入覆盖而不是追加。这样即使某条被重试多次，最终结果仍然只有一份。
- 分批提交并保留批次日志。每完成一小批就记录批次编号、起止标识、成功条数和失败条数。当再次被限流时，你能立刻知道损失边界。
- 对失败条目单独建队列。不要把它们混回主流程重跑，否则会反复触发同样的限流条件。单独队列可以配合更长的间隔慢慢消化。
假设一个场景：你有 500 个查询单元，脚本在第 180 个时被限流。可续跑形态下，前 179 个已经落盘并记录，恢复时从第 180 个继续，损失接近零；整批形态下，如果内存结果没有写出，前 179 个的调用成本就白费了。这个对比说明，改造写入方式的收益远大于调优重试参数。
一个会让上述结论失效的反例
如果百度司南工具返回的结果本身带有强时效性，且你的业务要求所有分片必须来自同一时间窗口，那么“逐条落盘、断点续跑”反而会引入新的问题：前半部分和后半部分可能对应不同的数据周期，拼在一起口径不一致。这种情况下，保护已有结果的正确做法不是续跑，而是把已落盘的部分标记为“不完整快照”单独存档，等限流解除后整批重取，再用快照做差异比对。也就是说，是否续跑取决于结果是否允许跨时间窗口拼接，而不是取决于限流本身。具体工具对时间窗口的处理方式，需要以你实际拿到的返回字段和官方说明为准，不能想当然。
下一步动作与验证方式
建议先做一次小规模演练：选 20 个查询单元，人为在中间触发一次中断，观察脚本能否只补跑剩余部分、且最终结果条数与预期一致。演练通过后，再把写入改造应用到全量脚本。验证时重点看两个指标：重复键是否被正确覆盖，断点标识是否能在重启后被准确读取。如果这两点成立，限流就从一个会丢数据的问题，降级为一个只影响耗时的问题。
