为什么读取很快，删除却这么慢？

两种操作走不同的配额通道。读取不改动状态，额度宽松；删除属于写操作，平台会把额度设得保守得多。所以能秒开的时间线，不代表能秒删。

触发限流之后要等多久？

不必等一整天。配额按滑动窗口补充，通常暂停一小段再发一个试探请求就能判断是否可以恢复。试探失败就把等待时间翻倍，连续两轮失败就收工。

风险不来自条数，而来自频率。分成几个片段、片间留间隔，账号表现基本与手动操作类似；把几百条压在一分钟内发完，才会触发验证和临时限制。

批量删帖慢下来的时候，多数人会先怀疑网络，再怀疑工具。真正的原因通常在配额的计算方式上：平台按时间窗口统计写操作的次数，窗口一旦打满，剩下的请求会被直接挡回来。理解这套计数逻辑，删除节奏就可以自己掌握。

下面讲三件事：配额是怎么算的、删除为什么比读取更容易撞墙、以及撞墙之后该怎么退。

常见的误解是「一天能删多少条」。实际规则更细：每个时间窗口内允许的请求数有限，窗口滑动着往前推进，配额不断被补充和消耗。这意味着你不需要等一整天，只需要在窗口打满时停一会儿。

读取推文列表的配额往往很宽松，因为它不改动任何状态。删除属于写操作，平台会把这类请求的额度设得保守得多。于是会出现一种很常见的错觉：既然能飞快地翻完整个时间线，删除也应该一样快。这两件事走的是不同的计费通道。

动手之前的顺序建议是：先用读取通道把目标范围摸清楚，再让写通道只负责执行。反过来做，写配额很快被浪费在试探上。

中间那一种性价比最高：不需要额外工具，把总量按分片切开，每片之间留出间隔，跑完一片记一行日志。最后一种更适合上千条的场景，因为靠人工记进度已经不现实。

收到限流响应时，正确的动作是停，而不是缩短重试间隔。常见的错误做法是失败就立刻重试，这会让平台判定为持续高频，把限制窗口越拉越长。

这套做法有个额外好处：账号不会在短时间内积累大量异常请求，减少被要求人工验证的概率。

最省配额的一步其实是免费的：把 X 数据归档下载到本机，在本机解析一遍，得出总条数和按风险分的类别。这一步不消耗任何接口配额，却能让后面的写操作量减少一大截，因为你可以只删该删的，而不是清空时间线。

对上千条的账号来说，先测量再删除通常能把实际操作量压到原来的三分之一以内。省下的配额就是省下的时间。

digital-footprint-health.shop 提供的正是那个免费的测量步骤：把 X 数据归档在本机解析，输出 0-100 健康评分和按风险排序的清单，全程不上传、不调用任何写接口。可以从免费体检开始，先看评分是怎么算出来的，再按删除实操流程分批执行。