📍 WDQWDWQD987AAAAA:216.73.216.226
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9ba0fc4e9ccc.html
📄

博客发布工具，脚本调用工具遇到限流时怎样保护已有结果

结论是：把“限流”当成一次可恢复的中断，而不是失败。能不能保住已有结果，取决于你在脚本里是否把已成功的返回先落盘、把失败项单独排队，并让下一次调用只补失败项。如果脚本把所有返回值攒在内存里最后统一写文件，限流一来进程被杀，前面成功的内容就全丢了，这是最需要先改的一点。

先判断限流会不会破坏已有结果

限流本身只是拒绝新的请求，不会主动删除你已经拿到的东西。真正造成丢失的是三种处理方式：批量结果只存在内存、失败后整批重跑、以及重跑时覆盖同名输出。前两种会让已完成的部分作废，第三种会把旧结果冲掉。所以保护已有结果的顺序是：先确认输出是否已经持久化，再确认重试的粒度是整批还是单条。

一个可区分的原因证据是：如果限流后日志里出现同一批内容被第二次请求，说明重试粒度太粗；如果日志显示请求成功但输出文件没有增长，说明写盘时机太靠后。这两种现象指向不同的修改点，不要混在一起处理。

把成功结果先落盘，再谈重试

具体动作是给每条记录一个稳定标识，成功一条就追加或更新一条，而不是等整批结束。这样即使进程中途退出，下次运行时脚本能读到已完成清单，跳过这些标识，只请求剩余部分。假设一次要处理 200 条，脚本在第 120 条被限流中断，如果每条成功即写盘，重启后只需补 80 条；如果整批写盘，重启后要重新请求 200 条，且第二次仍可能在第 120 条附近再次触发限流，形成反复。

这个动作的结果会直接影响下一步：能跳过已完成项，才谈得上缩短重试窗口；如果做不到，调低并发也只是把中断点往后推，并没有真正保护结果。

重试要区分限流和其他失败

限流通常有恢复时间，而参数错误、内容不合规、目标不存在不会因为等待而变好。把两者放进同一个重试队列，会让真正需要等待的请求被无意义的失败项拖慢，也会让你误以为限流还没解除。可行的做法是给失败项打上原因标记，只对限流类标记安排退避重试，其他失败单独输出人工核对。

• 限流类：等待后重试，且只重试未完成项。
• 参数或内容类：不自动重试，记录原始输入供修正。
• 未知类：先小批量试探，确认恢复后再放量。

退避时间不必追求精确公式，但要保证两次重试之间有明显间隔，并设置最大次数。次数用尽后停止并保留现场，比无限重试更安全。

一个会让上述结论失效的反例

如果脚本依赖的是同一次会话里才有效的临时凭证或分页游标，那么“只补失败项”并不成立：中断后游标失效，剩余部分无法从断点继续，只能重新建立会话。此时保护已有结果的正确做法不是断点续传，而是把已完成结果导出成独立文件，重新开始一轮完整请求，最后按标识合并去重。判断依据是：重启后能否在不重新请求已完成项的前提下拿到剩余数据。如果不能，就先合并、再重跑，而不是强行续传。

下一步动作与验收

先做一次小规模演练：故意在脚本中途终止进程，然后重新运行，观察它是否只请求未完成项、输出文件是否包含终止前的全部结果。演练通过，再放大批量。验收标准是重启后请求数量小于总数量，且最终输出条数与预期一致。若重启后请求数量等于总数量，说明落盘或去重还没生效，先修这一步，不要急着调并发。