友情链接工具，脚本调用被限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5c6b01cc6900.html
📄
友情链接工具，脚本调用被限流时怎样保护已有结果
先给结论：限流发生时，最该保护的不是“继续跑完”，而是把已经拿到的部分变成可复用、可核对、可续跑的结果。具体做法是让脚本每处理完一批就落盘一次，并把请求参数、时间戳、响应摘要一起写入同一条记录，这样即使后续调用被拒绝，你手里仍有一份能判断来源和完整度的中间产物，而不是一段只能重跑的内存数据。
先判断限流保护的是哪一层结果
友情链接工具的脚本通常有两层结果：一层是原始响应，比如对方页面上的链接区块、锚文本、rel 属性；另一层是加工后的判断，比如“是否互链”“是否nofollow”“是否同IP段”。限流打断的是请求层，但真正难重建的是加工层里的判断依据。
所以保护顺序应该反过来：先保住加工结果和它的证据链，再考虑原始响应的完整备份。假设你正检查一份 500 条的友链清单，脚本跑到第 180 条时开始返回 429。如果只存了“检查通过的域名列表”，你无法解释第 181 条之后是没查还是查了没通过；如果每条都存了请求时间、HTTP 状态、页面抓取片段和判定结论，你就能把第 180 条当成明确的分界线。
一个可区分的证据是：限流通常表现为连续多条请求失败，且失败集中在请求层；而页面本身的变化会表现为个别域名结果不同，失败分布是随机的。把这两类现象分开记录，后续才知道该等一等重试，还是该回头核对数据源。
把当前结果转成可续跑的项目文件
不要满足于一个结果表格。把输出拆成三个文件，续跑时只依赖第一个：
progress.json：记录已完成的条目 ID、最后成功的时间戳、当前批次号。它是续跑的起点。results.csv：每条一行，包含域名、请求时间、状态码、判定结论、证据摘要。这是给人核对的。raw/目录：按条目 ID 存放原始响应片段。空间不够时可以只留失败项和边界项。
动作很具体：在脚本里把“请求—判定—写盘”绑成一个事务，写盘成功后才更新进度。这样限流到来时，进度文件指向的一定是已经完整落盘的位置。结果是，下次启动脚本时你不需要猜“上次跑到哪”，而是直接读进度文件从下一条继续。这个动作会改变你的下一步：如果进度文件显示最后成功条目之后有连续失败记录，优先检查请求间隔和并发数，而不是怀疑友链数据本身。
限流后的重试要带条件，不能无条件循环
遇到限流直接 sleep 后重试，容易把已有结果再次拖入不确定状态。更稳的做法是给重试设三个条件：最大尝试次数、递增等待时间、以及“连续失败达到阈值就停止并保留现场”。
假设你设置单条最多尝试 3 次，等待时间按 2 秒、8 秒、30 秒递增。如果 3 次都失败，脚本不再继续，而是把该条目标记为 blocked，同时写入当时的响应状态。这个标记和“检查不通过”是两回事：前者说明你没拿到有效响应，后者说明你拿到了响应但判定为不合格。把两者混在一起，后续统计互链率时就会把限流造成的空缺算成负面结果。
这里有一个容易被忽略的取舍：降低并发能减少限流，但会拉长整批时间；提高并发能更快拿到结果，但一旦被限流，未落盘的部分就更多。如果你的清单只有几十条，低并发加逐条落盘更划算；如果清单很大且允许分天跑，按批次切分、每批结束就停，比一次性跑完更安全。选择依据是你能否接受“今天只拿到一部分且这部分可核对”，而不是追求一次跑完。
多个角色对同一份结果有分歧时怎么办
限流场景下最常见的分歧是：执行的人说“工具没跑完”，审核的人说“表里这些就是全部结果”，而决策的人看到的是缺了一截的汇总。把分歧转成可核对的项目，关键是让每个人看同一份进度文件，而不是各自手里的导出表。
具体可以这样做：在结果文件里加一列 batch_status，取值只有 complete、blocked、pending 三种。任何汇总数字都必须标注它覆盖了哪些批次。这样“互链率 40%”这句话就会被追问：它是基于全部条目，还是只基于 complete 的条目？一旦口径写清楚，分歧就从“谁对谁错”变成“我们还缺哪一段”。下一步动作也随之明确：补跑 blocked 条目，或先就用 complete 部分做阶段性判断。
需要提醒的是，请求量或抓取量归零，并不能单独证明你的处理方式正确。它也可能是对方临时关闭、网络中断、或脚本提前退出的结果。要证明是限流，至少需要看到状态码集中、失败时间接近、以及降低请求频率后恢复这三类证据中的两类。缺少这些证据时，先保留现场再判断，比急着下结论更稳妥。
最后，不同友情链接工具对限流的表现和重试机制并不一致，具体到某个工具是否支持断点续跑、是否保留原始响应，需要以你实际使用的版本和当期说明为准。通用原则只有一条：让每一次成功请求都留下可核对的痕迹，让每一次失败都留下可解释的标记。
