站长工具集：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5ba4c839c99b.html
📄
站长工具集：脚本调用工具遇到限流时怎样保护已有结果
限流发生时，最危险的动作不是等，而是立即重试。若脚本没有把已成功返回的数据先落盘，重试会把内存中尚未写出的结果冲掉，最终只剩最后一次失败状态。保护已有结果的核心原则是：把“调用”和“保存”拆成两步，让每次成功返回都先持久化，再决定是否继续请求。
一个反常现象：请求变少了，结果反而更容易丢
很多脚本在限流前跑得很快，返回一批就追加到列表里，直到全部跑完才统一写文件。限流一来，脚本卡在中间，列表只存在于进程内存。此时无论进程被终止、超时退出，还是你手动重跑，之前那批结果都没有独立副本。表面看是“请求被限制”，实际丢数据的原因是保存时机太晚。
这个现象有两种常见解释，需要区分清楚。
- 解释一：限流只是触发条件，真正原因是写入粒度太粗。如果每次成功返回都立刻写盘，限流只会让进度变慢，不会让已完成部分消失。
- 解释二：保存机制本身有问题，比如覆盖写、并发写冲突或临时文件未提交。这种情况下即使没有限流，进程异常退出也会丢结果。
区分两种解释的证据
判断属于哪一种，可以做一个假设性检查：在脚本里人为插入一次失败，观察已成功返回的数据是否还在磁盘上。
- 如果磁盘上只有空文件或旧文件，说明保存时机滞后，属于解释一。
- 如果磁盘上有部分数据，但内容错乱、字段缺失或行数对不上，说明写入方式有并发或覆盖问题，属于解释二。
- 如果数据完整但脚本仍从头重跑，说明缺少断点记录，属于进度状态没有独立保存。
这三种证据指向不同的修复动作，不能只靠“加大重试间隔”解决。
先落盘再重试的具体做法
把每次成功响应视为一个不可丢的事件，处理顺序应是：解析、追加写入、记录进度、再发下一次请求。具体动作可以拆成三步。
第一步，用追加模式写入。每批结果写入独立的行或独立文件，避免整表覆盖。若工具返回的是结构化数据，可以按批次编号命名，例如 batch_0001.json，这样即使后续失败，已写出的批次仍可单独读取。
第二步，单独记录进度游标。游标可以是页码、时间戳或上一条记录的标识。它和结果数据分开保存，脚本重启时先读游标，再从下一个位置继续，而不是从第一条重新请求。
第三步，让重试有上限并区分错误类型。限流返回通常有明确信号，遇到时应等待而不是立即重发。等待时间可以按次数递增，但必须设上限；超过上限就停止并保留现场，而不是无限循环消耗配额。
做完这三步后，限流的影响范围被压缩到“当前这一批”。下一批是否继续，取决于游标是否已安全写入，而不是取决于内存里还有多少数据。
什么时候该继续，什么时候该停
关键前提发生变化时，决策也要变。可以按以下条件判断。
- 可以继续：结果已逐批落盘，游标可读，且限流信号是暂时性的。此时降低请求频率、拉长间隔，继续推进不会破坏已有结果。
- 应当停止：限流伴随鉴权失败、配额耗尽或返回内容异常。继续重试可能触发更严格的限制，也可能把错误响应当成有效数据写入。
- 需要先修复再跑：磁盘上已有数据出现重复行、字段错位或游标指向不存在的记录。这属于解释二，继续调用只会放大混乱。
一个短例子说明比较方法：假设脚本计划请求一百批，跑到第三十批时被限流。若前二十九批已各自落盘且游标停在第三十批，重启后从第三十批继续，前二十九批不受影响；若所有结果只在内存列表里，重启后从第一批开始，前二十九批的请求全部作废。两者差距不在限流本身，而在保存动作发生的时刻。
把保护措施变成默认习惯
限流是外部条件，无法完全避免，但结果丢失是内部设计可以控制的。把“成功即保存”设为脚本的默认行为，比事后补救更可靠。每次调整调用逻辑时，先确认三件事：结果是否已独立落盘、进度是否可恢复、重试是否有明确上限。这三项确认过，限流就只是拖慢速度，而不是清空成果。
如果脚本还要长期运行，建议定期检查落盘文件的完整性和游标的一致性，发现不一致时先停止调用、修复写入逻辑，再恢复请求。这样下一次限流到来时，你手里始终有一份可用的已有结果。
