移动优化软件脚本调用遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4cd899ca68c5.html
📄
移动优化软件脚本调用遇到限流时怎样保护已有结果
先给结论：限流发生时，不要继续加大并发去抢进度，而应把已经返回的结果立刻落盘并标记批次边界，再用退避重试补齐缺口。已有结果的价值高于尚未拿到的结果，保不住已到手的部分，后面重试再多也是重复劳动。
先判断限流发生在哪一层
同一个脚本报错，原因可能完全不同。如果是接口返回明确的限流状态码或提示，说明是服务端在按频率拒绝，属于可预期的节流；如果是连接超时、DNS 失败或响应被截断，可能是网络抖动或代理层问题，未必是限流。两种情况的处理方式不同：前者应降速并等待，后者应先确认链路是否稳定。把这两类混在一起，容易在真正限流时误判为网络故障而反复重连，反而加重被限制的程度。
两种做法：边跑边存，还是先跑完再统一写
假设你手上是一个待处理的 URL 清单，脚本逐条调用接口获取移动端渲染结果。做法 A 是每拿到一条就追加写入本地文件或数据库；做法 B 是全部跑完再一次性写入。
- 做法 A 适用条件：任务量大、单次运行时间长、接口有明确频率上限。代价是写操作更频繁，需要处理并发写入和文件锁，但限流中断时损失最小。
- 做法 B 适用条件：任务量小、可一次跑完、接口稳定。代价是一旦中途被限流，前面所有结果都留在内存里，进程退出即丢失。
对大多数会遇到限流的场景，做法 A 更稳。判断依据很简单：如果一次运行需要几分钟以上，就默认它会中途被打断，按 A 设计。
把已有结果变成可续跑的检查点
仅仅存下来还不够，还要让下一次运行知道从哪里继续。每条记录至少带上三样东西：被处理的原始标识、结果内容、以及一个状态字段（成功、失败、待重试）。重跑时先读取已有记录，跳过成功项，只补失败和缺失项。这样限流恢复后不必从头再来。
一个假设的例子：清单有 500 条，跑到第 180 条时被限流，前 179 条已落盘并标记成功。此时正确动作是停止当前批次、记录断点位置、按退避策略等待，然后从第 180 条继续。如果直接重跑整个清单，前 179 条会被重复请求，既浪费配额，也可能让限流窗口延长。这里的数字只是说明比较方法，不代表任何真实接口的额度。
退避与并发要一起调，不能只改一个
遇到限流后常见的错误是只降低并发数，却保持固定的重试间隔。更稳妥的做法是两者同时收敛：先显著降低并发，再采用逐步拉长的等待间隔，例如每次失败后等待时间翻倍，并设一个上限。等到连续若干次成功后再缓慢恢复并发。动作的结果会直接影响下一步：如果降速后仍持续被拒，说明限制可能来自更上层（如共享出口 IP），此时继续在脚本内调参收益有限，需要考虑更换出口或错峰运行。
记录证据，别把单次现象当结论
限流期间应保留请求时间、响应状态和错误信息。请求量突然归零或抓取量下降，可能有多种解释：确实被限流、清单本身已处理完、脚本提前退出、或上游临时不可用。不能仅凭一次归零就断定是限流，也不能因为恢复后就认为处理方式正确。把这些记录留存，才能在下次判断时区分是频率问题还是其他原因。具体接口的限流规则、额度和恢复时间需要以该服务的实际文档为准，不同工具差异很大。
