百度下拉词工具，脚本调用工具遇到限流时怎样保护已有结果
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /c7a498cab271.html
📄
百度下拉词工具，脚本调用工具遇到限流时怎样保护已有结果
限流发生时，第一优先级不是继续拉数据，而是把已经拿到的结果变成可恢复的本地文件，再决定是降速续跑还是换查询口径。判断依据只有两个：已采集结果的唯一性是否可靠，以及剩余查询能否被拆成更小的批次。
先判断：限流是临时拦截还是口径过宽
脚本收到限流信号时，通常有两种可能。一种是短时间请求过于集中，等待后降低并发即可恢复；另一种是查询词表本身过宽，例如把大量长尾词、竞品词、品牌词混在同一轮里跑，导致请求量长期高于工具能承受的节奏。两种情况的处理方向不同，先区分再动手。
可用的区分证据包括：限流是否集中在某一类词上、降低并发后是否仍快速触发、同一批词换时间段重跑是否表现一致。如果只有某一类词持续触发，更可能是口径问题；如果所有词都在相近请求量后触发，更可能是频率问题。这里要注意，请求量归零或抓取量下降并不能单独证明限流已经解除，也可能是脚本提前退出、任务队列为空或工具返回结构变化，需要结合日志和本地文件行数一起看。
条件一：已有结果唯一且可去重，先落盘再续跑
如果每条结果都能用“查询词+下拉位置”或类似组合键唯一标识，就应该先做落盘保护。具体动作是：在脚本每次写入前，把结果追加到本地文件而不是只留在内存；同时记录已完成的查询词，形成断点清单。下一步续跑时，只读取断点清单之外的词，避免重复请求已经成功的部分。
这个动作的结果会直接影响后续选择：如果落盘文件行数与断点清单能对上，说明已有结果可复用，可以放心降速续跑；如果对不上，说明写入过程本身有丢失，应先修复写入逻辑，而不是急着换工具或换代理。假设一个场景：脚本跑了三百个词后触发限流，本地文件只保存了前两百个词的结果，断点清单却记录到第二百八十个。此时正确做法是把断点回退到第二百个词，而不是从第二百八十个继续，否则中间八十个词会永久缺失。
条件二：结果无法可靠去重，先冻结当前批次
如果结果里没有稳定唯一键，比如只保存了下拉词文本而没有记录它来自哪个查询词、哪个位置，那么续跑会造成重复和错位。此时不要继续追加，而应把当前批次整体冻结为一个独立文件，标记为“未完成、不可续跑”，然后重新设计输出结构，再开新一轮。
冻结的好处是保留证据。后续如果要判断限流是否与查询口径有关，可以拿这批冻结数据做对照，而不是靠记忆复述。实施时至少记录：批次开始时间、已请求词数、触发限流时的最后一条日志、文件行数。这些字段不需要复杂工具，纯文本即可。
降速续跑时的取舍：并发、间隔与批次大小
决定续跑后，常见取舍是降并发还是拉大间隔。降并发减少同时请求数，适合工具按并发维度限流的情况；拉大间隔减少单位时间请求数，适合按频率维度限流的情况。两者可以同时小幅调整，但不建议一次改太多，否则无法判断哪个改动真正起了作用。
更稳妥的做法是把剩余词拆成小批次，每批完成后主动暂停并检查本地文件是否完整。批次大小的选择依据是：单批能在触发限流前跑完，且失败时损失可接受。如果一批五百个词总是中途触发，就降到一百个词一批，用完成率而不是单次速度来衡量是否值得。
例外：这些情况不适合继续用同一脚本硬跑
- 工具返回结构已经变化，字段缺失或错位，继续跑只会积累脏数据。
- 限流伴随账号或调用凭证异常提示，此时续跑可能扩大影响范围。
- 查询词表本身需要先清洗，比如包含大量重复词、空白词或明显无关词。
- 已有结果已经满足当前决策需要，继续采集的边际价值低于维护成本。
遇到这些例外，正确动作是停止脚本、保留现有文件、先处理词表或输出结构。是否更换工具、是否调整调用方式，需要结合该工具当前的实际说明核对，不能凭旧经验假定入口和限制仍然一致。保护已有结果的核心不是跑得更快，而是让每一次中断都不丢掉已经确认可用的部分。
