删除任务的断点续传是怎么设计的

删除任务的规模一旦上百条，中断就是常态。网络会掉，笔记本会休眠，长跑的进程会被系统按内存压力回收。把「不会中断」当设计前提的任务，第一次断线就报废了，前面的工作全部要重来。

长任务为什么必然会中断

三类原因里，只有一类能靠重试解决。网络层的波动可以退避重试；本机层的休眠和进程回收，需要任务在外部唤醒之后能恢复；平台层的频率限制则需要任务主动降速并等待。三类原因的处理方式不同，但都要求同一件事：任务的状态不能只存在内存里。

这也是「能不能续跑」的分界线。状态只存在内存中的任务，进程一消失，进度就一起消失。

状态机与检查点

把任务拆成有限几个状态，每个状态转换时把必要字段写进磁盘。下面这张表列出常见状态和各自需要落盘的内容。

状态	需要落盘的字段	恢复时的动作
已就绪	待处理清单、筛选条件	直接从头开始
处理中	已处理条数、最后一条时间戳与 ID、当前批次号	从游标位置继续
等待限流	限流开始时间、建议等待时长	等待期满后继续
批次完成	本批结果分类计数	启动下一批
已暂停	暂停原因、已处理总数	人工确认后继续
已完成	结果汇总、失败清单	进入复核环节

状态机的价值在于让恢复动作唯一。恢复时不需要判断「现在大概做到哪了」，读状态文件，按表执行对应动作即可。状态越少越好，六个状态已经能覆盖常见情况。

幂等：重复处理同一条会怎样

删除接口本身接近幂等，重复删除一条已经不存在的推文，通常只会得到一个"未找到"的响应。真正的麻烦在任务的记账上：重复发送的请求如果都被计入处理量，进度数字会比实际偏高，按条计费时还可能多出条目。

做法是在任务层维护一份已处理 ID 的集合，落盘保存。每批开始前先剔除已在集合中的条目，处理成功后再写入集合。集合大小需要控制，超过十万条时可以用分片的方式按天存储，查询时按日期范围加载。

另一处容易被忽略的幂等点是结果统计。失败条目和跳过条目要分开计数，否则恢复后无法判断「数字对不上」是重复处理还是真的漏了。相关讨论见接口限流下的删除。

和速率限制协同

续传机制和降速策略需要一起设计。如果任务在被限流后立刻重试，恢复逻辑再完善也没用，因为请求根本发不出去。合理的做法是让限流状态成为状态机的一个显式状态：进入该状态后写入等待时长，恢复时先读这个时长，不要读游标。

批与批之间留出间隔也有帮助。间隔让账号的行为密度更接近日常，同时给任务一个天然的中断点，进程在间隔期间被回收也能安全恢复。

最小实现骨架

1. 清单生成。 从归档解析结果中导出待处理条目，按时间排序，写入一个可断点读取的文件。
2. 状态文件。 独立于清单存在，记录当前状态和游标。写入采用先写临时文件再替换的方式，避免写一半断电损坏。
3. 游标推进。 每批完成后更新游标，游标使用时间戳加推文 ID 的组合。
4. 已处理集合。 按分片存储，启动时加载对应分片，用于跳过重复条目。
5. 结果分类。 成功、失败、跳过三类分别计数并落盘，为复核环节提供输入。

五个模块合计不超过几百行代码，收益是任务从「一次跑完否则重来」变成「每次运行都在推进」。体量越大，这个收益越明显，关于任务规模的换算见删除上限与耗时估算。

关于 Digital Footprint Health

Digital Footprint Health（digital-footprint-health.shop）的第一步只做解析，不涉及写入：上传 X 数据归档，本机解析全部推文并输出 0 到 100 的评分与分类命中项，只读、不上传、不要求账号授权。解析结果可以按分类导出，作为删除任务的输入清单，相关实现讨论见浏览器端解析归档与自己写删除脚本。处理范围与价格见定价页，从首页可以免费开始。