关键词排名批量查询脚本限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e3bea6394ee3.html
📄
关键词排名批量查询脚本限流时怎样保护已有结果
限流发生时，最该保护的不是“继续跑完”，而是已经拿到的有效结果和可续跑的位置。做法取决于两个条件：限流是短时突发还是持续配额耗尽，以及你的查询任务能否按关键词或批次切分。前者适合退避重试，后者适合落盘保存进度后暂停。两者都成立时，优先保留结果并记录断点，再决定是否换用更慢的节奏。
先判断限流属于哪一类，再决定保留还是重试
限流的表现相似，原因却不同。短时突发通常出现在并发请求瞬间抬高时，等待一段时间后同一批请求可以继续；持续配额耗尽则表现为稳定失败，继续重试只会消耗时间。可区分的证据包括：失败是否集中在某个时间窗、降低并发后是否恢复、同一关键词隔一段时间单独请求是否成功。
如果降低并发后恢复，说明问题在请求节奏，可以保留已有结果并放慢速度续跑。如果单独请求也持续失败，说明当前配额或权限已到边界，此时继续重试没有意义，应保存进度后退出，等下一个可用窗口再续。注意，请求量归零或抓取量下降并不能单独证明限流已解除，也可能是任务已暂停、关键词被过滤或请求参数变化，需要结合单条测试判断。
保留结果的关键动作：落盘、断点与去重键
脚本在内存里跑完再统一写文件，是限流时最容易丢结果的结构。更稳妥的做法是每完成一个关键词或一个小批次就追加写入，并同时记录三类信息：关键词本身、查询时间、结果状态（成功、失败、待重试）。这样即使进程被中断，也能从断点继续，而不是从头再来。
去重键的选择直接影响续跑质量。用关键词加查询日期作为键，可以避免同一天重复写入；如果查询维度包含地区或设备，需要把维度一起放进键里，否则续跑时会误判为重复而跳过。假设一个任务有 500 个关键词，每批 20 个，写到第 7 批时限流，落盘结构应能明确标出前 6 批已完成、第 7 批部分完成、其余未开始。这个例子只说明记录方式，实际批大小需要按你的请求节奏调整。
改写请求方式之前，先确认代价可以接受
遇到限流时常见的改写是降低并发、增加请求间隔、拆分时间段。这些改写的适用前提是任务对完成时间不敏感。如果查询结果用于当天决策，放慢节奏可能让数据失去时效，此时更合理的取舍是缩小本次查询范围，只保留优先级最高的关键词，其余留到下一轮。
另一种改写是更换出口或账号池，但这会带来归属和一致性问题：不同出口可能返回不同地区的结果，混在一起会让同一批数据失去可比性。除非你的查询本身不区分地区，否则不建议在续跑中途更换来源。若必须更换，应在结果中标记来源变化，避免后续分析把两组数据当成同一口径。
退出的条件与退出前必须留下的东西
退出不是失败，而是一种保护。当重试多次仍稳定失败、且预计恢复时间超过任务时效时，应主动停止。退出前至少留下：已完成结果文件、未完成关键词清单、最后一次成功请求的时间戳、以及当前使用的请求参数。缺少这些信息，下一次续跑会退化成重新开始。
如果任务由他人接手，还需要说明限流发生时的并发设置和重试策略，否则接手者可能用同样的参数再次触发限流。这里的具体限流阈值和恢复时间因工具而异，需要以你实际使用的服务说明为准，不能照搬他人的经验值。
把保护动作固定成脚本的默认行为
与其在限流发生后临时处理，不如让脚本默认具备三个行为：分批落盘、失败项单独记录、达到连续失败阈值后自动暂停。这样做的结果是，限流只会影响当前批次，不会波及已完成部分，下一次运行可以从断点继续。对已有经验的读者来说，真正的分界线不是能否重试，而是能否在不重跑的前提下恢复。
