网站历史记录查询脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /be7a9f9634ca.html
📄
网站历史记录查询脚本调用工具遇到限流时怎样保护已有结果
遇到限流时，第一优先级不是继续请求，而是把已经拿到的结果落盘、标记断点位置，再决定保留、改写还是退出。只要结果还停留在内存或临时变量里，等待重试就可能因进程被终止而全部丢失；把已完成条目写入本地文件并记录最后成功的时间点或标识，是缺权限、缺完整数据时仍能执行的最小动作。
先落盘再谈重试：保护结果的最小动作
限流信号通常表现为连续失败、返回体变短或响应明显变慢。此时继续循环只会消耗剩余配额，正确做法是立即停止新请求，把内存中的结构序列化到磁盘。可执行的顺序是：
- 把每条已成功记录写成一行 JSON 或 CSV，追加写入，避免整文件重写。
- 单独记录断点，例如最后成功处理的标识或时间戳，而不是只记条数。
- 记录失败原因分类，区分限流、超时、数据不存在，避免下次重试时混淆。
这样做的直接结果：即使进程被杀，下次也能从断点续跑，不必从头再查。需要说明的是，落盘成功只证明本地保留了这批结果，不能推出这些结果完整或准确，也不能推出限流已经解除。
保留、改写、退出：三种取舍的适用前提
保留适用于已有结果本身可用、只缺后续条目的情况。前提是断点可定位、结果格式稳定。此时保留全部文件并暂停任务，等配额恢复后从断点继续即可。
改写适用于限流由请求节奏触发的情况。前提是你能调整请求间隔、批量大小或并发数，且目标数据不要求实时。改写后应先用小批量验证是否仍触发限流，再逐步放大；如果小批量仍失败，说明问题不在节奏，继续改写没有意义。
退出适用于限流持续、权限或数据本身不可得的情况。前提是继续投入的时间成本高于结果价值。退出前仍要落盘并写清已完成范围，方便后续判断缺口。
判断限流还是其他原因：可区分的证据
把限流当成唯一解释容易误判。可对照的证据包括：失败是否集中在固定时间窗口、是否与请求频率同步出现、单独一次请求是否成功。如果单独请求成功而批量失败，更偏向节奏问题；如果所有请求都失败且与频率无关，更可能是权限或目标数据状态变化。请求量归零或抓取量下降也不能单独证明处理正确，它同样可能来自任务提前结束、目标地址变更或本地程序异常。
一个假设的短例子
假设脚本需要查询 500 条记录，处理到第 180 条时开始连续失败。此时停止请求，把前 180 条写入 done.jsonl，并在 state.txt 中记下第 180 条的标识，然后退出进程。恢复后先只请求第 181 条：若成功，说明只是节奏问题，可加间隔继续；若仍失败，则先核对权限与目标状态，而不是直接重跑全部 500 条。这个动作把损失限制在已保存范围内，也让下一步判断有依据。
恢复前需要确认的条件
恢复任务前，先确认断点文件可读、结果格式与首次运行一致、失败分类已记录。若这些条件不满足，先修数据再重试，否则续跑可能覆盖或错位已有结果。限流本身不承诺何时解除，也不保证恢复后一定成功；能确定的是，落盘和断点记录让已有结果不再依赖单次运行的成败。
