分词工具：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /00a449c300c2.html
📄
分词工具：脚本调用工具遇到限流时怎样保护已有结果
结论先给：如果限流发生时你还没有把已返回的分词结果落盘，那么“保护已有结果”的唯一可靠动作是立即停止继续调用，并把当前内存中的结果写成带批次标识的本地文件；否则重试逻辑一旦覆盖或清空缓冲区，已经拿到的分词就会丢失。这个结论有一个明确的反例：当工具本身以流式方式逐条返回、且你的脚本每收到一条就同步追加写入文件时，限流并不会造成已有结果丢失，此时继续等待重试反而更划算。
先判断你的结果是否真的处于危险中
限流本身只是拒绝新的请求，它不会主动删除你已经收到的数据。危险来自脚本的处理方式，而不是限流这个事件。常见的高危写法有三种：把整批结果收集在一个列表里、等全部请求成功后再统一写文件；在重试时用新结果直接赋值给同一个变量；捕获异常后直接退出进程而不做收尾写入。这三种情况下，限流导致的失败会连带丢掉此前成功返回的分词。
可以用一个假设例子来区分：假设你调用分词工具处理 200 条文本，前 80 条已返回分词结果，第 81 条触发限流。如果脚本是“全部成功才写盘”，那么这 80 条结果会随进程退出而消失；如果脚本是“每 10 条追加写入一次”，你最多损失当前未写满的不足 10 条。两者的差别不在限流强度，而在写入时机。
限流发生时仍然可执行的最小动作
缺少完整数据或权限时，不必等限流解除再想办法。可以立刻做的最小动作是：把已确认返回的结果序列化为一行一条的文本或 JSON Lines，用<输入标识>.part这类临时后缀命名，并同时记录已成功处理的最后一条输入的位置标记。这个动作不依赖任何平台的额外权限，只需要脚本自身能写本地文件。
这个动作的结果会直接决定下一步：如果落盘成功，你可以安全地重试剩余部分，并在恢复后把.part文件合并进主结果，不需要重新请求已经成功的条目；如果落盘失败，说明问题可能出在磁盘或权限而不是限流，此时继续重试调用只会重复消耗配额，应该先解决写入路径。需要说明的是，落盘成功只能证明“这批已返回的结果被保存了”，不能推出“剩余请求一定会成功”，也不能推出“限流已经结束”。
重试策略要围绕断点而不是围绕次数
遇到限流后盲目按固定次数重试，容易在恢复的瞬间再次打满配额，把刚拿到的结果又推入危险区。更稳的做法是让重试从断点继续，并给每次重试之间留出递增的等待间隔。判断断点是否可靠的证据是：.part文件中最后一条记录的输入标识，能与原始输入列表对上位置；如果对不上，说明写入过程中出现了部分写入，需要按行校验后再续跑。
这里要避免一个误判：把“重试后请求数归零”或“抓取量下降”当成限流已解除的证据。请求量归零还可能是因为脚本已经退出、等待时间过长、或输入列表本身已经处理完，这些都与限流状态无关。只有一次新的、成功的返回，才能作为可以继续的弱证据。
什么时候继续等待比立刻落盘更合适
前面提到的反例值得展开：当分词工具支持流式返回，且你的脚本每收到一条就追加写入，限流只会中断后续条目，不会影响已写入内容。这种情况下，立即停止并落盘的意义不大，因为结果本来就已经在文件里。更合适的动作是保留当前连接状态、按服务端建议的等待时间重试，避免反复重建会话带来的额外开销。
判断自己属于哪种情况，可以看一个信号：内存中是否存在“已返回但未写入”的结果。如果存在，先落盘；如果不存在，先等待。这个判断不需要知道工具的具体限流阈值，也不需要完整的历史调用数据。
恢复之后怎样合并而不破坏已有结果
续跑完成后，不要直接用新结果覆盖主文件。可以按输入标识做一次合并：以主结果中已存在的标识为准，只补充缺失的标识，并保留一份合并前的备份。这样即使续跑阶段因为参数变化导致同一输入的分词结果不同，你也能看出差异来自哪一次调用，而不是让旧结果被静默替换。合并后应抽查若干条，确认分词边界与原始输入对应，再决定是否清理.part临时文件。
如果合并时发现同一输入标识出现两份不同结果，不要默认新结果更正确；这通常说明两次调用使用了不同的分词参数或词典版本，需要先核对参数再决定保留哪一份，否则后续基于分词的分析会混入不一致的口径。
