反向链接查询脚本遇限流，怎样保住已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /006db15e8952.html
📄
反向链接查询脚本遇限流，怎样保住已有结果
限流发生时，最该保护的不是“继续查完”的执念，而是已经拿到的原始响应和已确认的记录。可行做法是先把结果落盘、记下中断位置，再决定是降速续跑还是换查询口径；如果结果只存在内存里，任何重试都可能把已有数据覆盖掉。
先判断是限流还是别的问题
脚本返回错误时，不要立刻归因于限流。常见可区分的原因有三类：一是HTTP状态码明确为请求过多，通常伴随重试等待提示；二是连接超时或DNS失败，表现更像网络或目标端不稳定；三是返回了正常结构但字段为空，这可能是查询对象确实没有可返回的记录，也可能是参数写错。把这三类混在一起，会让人误以为“被限流了”，从而做出错误的降速或换工具决定。
一个实际动作是：在脚本里为每次请求单独记录时间戳、请求参数、状态码和响应体前若干字符。这样即使中途被限流，也能回看最后一次成功请求长什么样。如果状态码是明确的限流信号，下一步应进入退避重试；如果是超时，应先检查网络和并发数，而不是直接拉长间隔。
条件一：还能继续跑，就降速续跑并保留断点
当你确认只是短时限流，且任务允许较长时间完成时，优先选择降速续跑。具体做法是把“已完成的查询单元”写入一个持久化文件，例如每处理完一个目标就追加一行，包含目标标识和结果摘要。下次启动时先读这个文件，跳过已完成项。这样即便进程被杀掉，也不会从头再来。
降速的幅度不必凭感觉。可以先记录限流前每分钟成功请求数，再把并发数减半、请求间隔加倍，观察是否还会触发限流。若仍触发，继续按同一比例调整。这个动作的结果会直接影响下一步：如果降速后能稳定跑完，就保留当前参数；如果仍然频繁中断，说明需要换查询口径，而不是无限拉长等待。
短例子（假设）：某脚本原本并发10、间隔0.2秒，跑到第300个目标时开始返回限流状态。改为并发3、间隔0.8秒后，能连续完成剩余目标。这里的关键不是具体数字，而是“先落盘、再降速、用断点续跑”的顺序。
条件二：不能继续跑，就先固化已有结果再换口径
如果限流持续时间长，或者任务本身有硬性时间窗口，继续等待的代价高于换方案，就应停止当前脚本，把已有结果整理成可核对的清单。整理时区分三类内容：已成功返回并保存的原始记录、只拿到部分字段的残缺记录、以及完全未执行的查询单元。这个分类决定了后续动作——已成功的可以直接使用，残缺的需要标记为待补，未执行的重新排期。
换口径不是换一个工具随便再查一遍。更稳妥的做法是缩小单次查询范围，例如把一次大批量查询拆成按时间分段或按目标分组的小批次，每批完成后立即保存。这样即使新口径也被限流，损失也只限于当前小批次。需要注意，换口径后得到的结果与旧结果可能存在字段差异，合并前应保留来源标记，避免把不同口径的数据混成一条无法追溯的记录。
把分歧转成可核对的项目
多个角色对“已有结果是否够用”常有不同理解：有人觉得已经拿到大部分，有人坚持必须全部查完。与其争论，不如把分歧写成一张核对表，列出每个查询单元的当前状态、最后一次成功时间、结果存放位置和缺失字段。任何一方想推进，都要先指出表中哪一项不满足，以及满足它需要什么动作。
- 已确认：原始响应已保存，字段完整，可被其他人复现。
- 待确认：有响应但字段缺失，或保存位置不明确。
- 未执行：因限流中断，尚无任何结果。
这张表的作用是让“继续跑”和“先交付”两种选择都有依据。如果待确认和未执行占比很小，可以先交付已确认部分；如果占比大，则应优先补跑，而不是在争论中消耗时间。
例外与需要核对的信息
以上做法默认脚本能写入本地或可控存储。如果运行环境不允许持久化，保护已有结果的难度会显著上升，此时应优先考虑把结果输出到外部日志或由调用方接收，而不是依赖进程内存。
另外，不同工具对限流的判定和重试建议并不相同，具体状态码含义、退避策略和配额规则需要以你实际使用的工具文档为准。不要根据一次限流就断定某个工具永久不可用，也不要因为某次未被限流就认为可以无限提高并发。把每次中断当成一次需要记录和核对的信号，而不是一个需要立刻绕过的障碍，才能让后续查询建立在可验证的结果之上。
