站长工具平台：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b97d1ceff820.html
📄
站长工具平台：脚本调用工具遇到限流时怎样保护已有结果
先保住已有结果，再决定是否继续调用。遇到限流时，最危险的动作是立刻重试并把上一轮返回覆盖掉；更稳妥的顺序是：先落盘原始响应，再标记哪些条目已完成、哪些只完成一半，最后根据限流类型选择保留、改写请求或退出。限流不等于数据失效，它只说明当前调用节奏需要调整。
先落盘再重试：把原始响应和解析结果分开存
很多脚本把请求、解析、入库写在同一个循环里，一旦中途被限流，内存里的中间结果随进程结束一起丢失。要保护已有结果，至少把两层数据分开：原始响应（状态码、响应头、响应体原文、请求参数、时间戳）和解析后的结构化结果。原始响应是证据，解析结果是可以重算的派生数据。
具体动作：在每次请求返回后立即追加写入一个本地文件或临时表，而不是等整批跑完再统一写。这样即使后续全部被限流，前面成功的条目仍然可核对。判断下一步时，先看原始响应里成功条目的比例，而不是看脚本最终退出码——退出码只说明进程结束方式，不说明数据完整度。
区分限流的三种信号，别用同一个对策
限流的表现不同，处理方式也不同。可核对的区分依据是响应状态码、响应头中的重试提示字段，以及返回体是否为空或为错误结构。
- 明确拒绝型：状态码直接表示请求过多，通常带有建议等待时间。此时继续密集重试只会延长封禁窗口，应保留已成功条目，按建议等待后再从断点续跑。
- 静默降级型：请求返回成功状态，但内容为空、字段缺失或明显是占位结构。这种最容易被误当成“查无结果”而覆盖旧数据。需要把“成功但无有效内容”单独标记，不能直接写入空值。
- 部分成功型：批量接口中一部分条目返回正常、一部分被拒。此时要按条目粒度记录状态，而不是按整批成功或失败。
如果只看到请求量归零或抓取量下降，不能单独证明限流已经解除，也不能证明之前的处理正确。请求量归零还可能是脚本提前退出、网络中断、目标返回结构变化导致解析失败。要区分这些解释，需要回看原始响应里的状态码分布和时间戳间隔。
保留、改写、退出：三种取舍各自成立的前提
保留适用于：已成功条目覆盖了本次任务的关键部分，且原始响应可核对。此时停止调用，把已有结果标记为“部分完成”，先交付可用部分，再安排下一轮补缺。前提是你能说清缺哪些条目，而不是笼统地认为“没跑完”。
改写适用于：限流由调用节奏引起，且目标允许降低频率。可改写的方向包括拉长请求间隔、缩小单次请求的条目数、增加本地缓存避免重复查询。前提是改写后仍能满足任务对时效的要求——如果数据本身有强时效，放慢节奏可能让结果失去意义，这时改写就不成立。
退出适用于：限流伴随账号或权限层面的限制，或目标返回结构已变化导致解析持续失败。继续调用可能扩大影响范围，此时应保留证据、停止请求，先确认限制的性质再决定是否恢复。
假设一个场景：某脚本计划查询 500 个条目，跑到第 180 个时开始连续收到拒绝响应。若前 179 个的原始响应已落盘，正确动作是停止、记录断点在第 180 个、把 179 条标记为已完成；下一轮从第 180 个开始，而不是从头重跑。这个假设只用于说明断点续跑的比较方法，不代表任何具体工具的现状。
让下一次调用可恢复：断点和去重是核心
保护已有结果不只是保存文件，还要让下一轮能接着跑。两个必要机制：
- 断点记录：记录最后成功处理的条目标识，而不是只记录循环下标。条目顺序变化时，下标会错位。
- 去重键：为每个条目定义稳定唯一键，写入前先判断是否已存在，避免重复调用和重复覆盖。
动作与结果的关系很直接：如果只保存解析后的结果而不保存原始响应，当解析逻辑有误时无法回溯，只能重新调用，而重新调用又可能再次触发限流；如果保存了原始响应，就可以在本地重算解析结果，不增加任何请求。这一步决定了你在限流后是“有据可查”还是“只能重来”。
核对工具行为时的边界
不同站长工具平台对调用频率、返回结构和错误提示的处理方式并不一致，具体阈值、字段名和提示文案需要以你实际使用的工具文档和真实响应为准。不要根据旧教程或他人截图推断当前行为，也不要假设某个状态码在所有工具中含义相同。稳妥做法是先用少量请求观察真实响应，再据此设计落盘和重试逻辑。
限流发生时，先保住原始响应和断点，再判断是保留部分结果、改写调用节奏还是暂时退出。这三步的顺序比选择哪一个更重要。
