爱站网：脚本调用遇限流时如何保住已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d5cdb3967325.html
📄
爱站网：脚本调用遇限流时如何保住已有结果
限流发生时，最危险的不是拿不到新数据，而是把已经取回的结果覆盖掉或丢失。可行的最小动作是：立即停止重试、把当前结果落盘并记录断点，再决定是否继续。但“保住结果”不等于“结果完整”，也不等于“限流已解除”，这两点需要分开判断。
先分辨两种限流：配额耗尽还是节奏过快
脚本被拦下时，常见两种解释。第一种是配额耗尽：调用方在某个时间窗口内的可用次数已经用完，继续请求只会持续失败，直到窗口重置。第二种是节奏过快：单次请求本身没问题，但短时间内的并发或频率触发了保护，降低速度后通常能恢复。
两者的处理方向相反：配额耗尽时重试是浪费，应该等待或换用其他已授权途径；节奏过快时完全停止反而拖长任务，正确做法是降速、串行化、加间隔。把两者混为一谈，就会出现“越等越久”或“越重试越被封”的误判。
用三个证据区分，而不是靠感觉
能区分这两种解释的证据有三类。第一，看失败的时间分布：如果失败集中出现在任务开始后不久、随后长时间稳定失败，更像节奏问题；如果任务前段一直正常、在某个累计量附近突然集体失败，更像配额问题。第二，看单个请求的最小测试：隔一段较长时间只发一次请求，若成功，说明额度或窗口可能已恢复；若仍失败，更可能是权限或配额层面的限制。第三，看返回信息的类型：明确的额度提示、鉴权失败与单纯的连接中断，指向不同的原因。这三类证据需要同时看，单看任何一条都可能误判。
需要提醒的是，请求量归零或抓取量骤降本身不能单独证明处理正确。它也可能来自目标端临时故障、网络中断、脚本提前退出，甚至只是任务本来就没启动。把“没有报错”当成“限流已解决”，是常见的错误结论。
保住已有结果：落盘、断点、幂等三件事
限流一来就丢数据，通常是因为脚本把结果攒在内存里、最后统一写文件。改成边取边写，损失就小得多。具体可以按下面的顺序做：
- 立即停止重试，避免把配额或信任额度进一步消耗掉。
- 把当前结果追加写入，而不是覆盖写入；每条记录带上时间戳和来源标识。
- 记录断点，例如已完成的页码、偏移量或最后一条记录的主键，写进单独的进度文件。
- 让写入幂等，用主键或唯一标识去重，这样重跑时不会产生重复行。
- 下次启动先读断点，从断点继续，而不是从头再来。
这个动作的结果会直接影响下一步：如果断点可靠、写入幂等，那么恢复时只需处理剩余部分，代价可控；如果断点不可靠，就只能整段重跑，等于把限流风险再承担一次。所以断点设计比“多存一份备份”更关键。
一个假设例子：降速后恢复，说明什么
假设一个脚本需要取回 500 条记录，在第 120 条附近开始连续失败。此时先落盘并记下断点，然后只发一次探测请求：
- 若探测成功，把并发降到 1、请求间隔放大到原来的若干倍后从第 121 条继续，观察是否稳定推进。稳定推进说明更可能是节奏问题。
- 若探测仍失败，且失败信息指向额度或权限，则等待窗口重置或改用其他已获授权的途径，不要继续硬试。
这个例子里，降速后恢复只能说明当前节奏下可以继续，不能推出目标端没有总量限制，也不能推出长期稳定。数字只是说明比较方法，不代表任何真实额度。
缺少完整数据时仍可执行的最小动作
当你既没有完整权限、也看不到明确的配额说明时，仍然可以做三件事：一是把已取回的部分按上述方式落盘并标注为“不完整”；二是保留失败样本的时间与返回信息，作为后续判断依据；三是暂停自动重试，改由人工决定是否继续。由此能得到的结论仅限于“已取回部分可用、缺失部分未知”，不能据此推断整体分布、总量或趋势。把不完整结果当完整结果使用，比限流本身更容易造成后续决策偏差。
