批量下载任务被SIGTERM中断后，我是靠3步快速完成文件整理的

上周在hermes项目的资源同步场景里，跑了一个批量下载云盘文件的后台任务，跑了半小时突然收到进程被SIGTERM终止的通知，输出日志只保留了最后1978个字符，满屏的✅❌看得人眼花：到底哪些文件下完了？哪些是本来就跳过的？哪些是要补跑的？要是盲目全量重跑，至少得多花1个小时，最后靠3步快速理清了所有文件，还顺便把后续检索的效率提了一大截。

一、先做完整性校验，别急着重跑任务

后台进程被终止的原因后来查了是系统内存不足触发的OOM killer，不是脚本本身的问题。首先第一步是把输出日志里的状态标识全量拉出来：✅代表下载成功，❌代表下载失败，还要区分两类特殊情况：一类是脚本主动跳过的资源（比如权限不足、格式不支持），一类是资源本身不存在导致的失败。
比如日志里的「❌ 无链接: 小王子.txt」，乍一看是下载失败，实际上云盘里根本没有这个文件的分享链接，补跑100次也没用。一开始我误以为所有❌都要补跑，把这个无效项加到了补跑列表里，后来查了云盘分享记录才发现这个文件早就被删除了，白浪费了10分钟排查。后来我加了个「资源有效性校验」的步骤：先访问分享链接确认可下载，再纳入补跑列表，直接省掉了所有无效补跑的工作量。
另外还要注意异常状态的文件，比如日志里的「✅ readme.txt (0KB)」，大小是0，大概率是空文件，要么是下载时出错要么是本身就是空文件，后续整理的时候可以直接清理掉，避免占用存储空间、干扰后续文件去重。

二、按业务维度分类，从根源降低检索成本

校验完完整性，发现总共只有3个需要补跑的文件，剩下的都是已经下载成功的，一共20多本术数典籍、几本文学名著、还有1个Tor浏览器安装包。一开始我直接把所有文件都丢在同一个文件夹里，后来找《风水宝鉴完整版》翻了快10分钟，才想起来按业务维度分类：

• 术数典籍：把所有风水、紫微斗数、梅花易数、相法的文件归到一类，同名的不同作者版本加作者后缀区分，比如「梅花易数-郑轲版.pdf」「梅花易数-李科儒版.pdf」，避免后续混淆；
• 文学名著：把《简爱》《罗密欧与朱丽叶》这类公版书归到一类；
• 工具软件：把Tor浏览器的dmg安装包单独存放。
  之前没分类的时候，找陆斌兆的《斗数初级讲义》要在几十个文件里翻，分类之后再找同类资料，最多2秒就能定位到，后续如果要给这些资料加索引、做内容梳理，分类后的效率至少能提3倍。

三、两个容易被忽略的踩坑点

第一个坑就是刚才提到的「无链接」类失败项，不能一概而论当成下载失败，很多云盘分享链接本身就会过期、被删，先校验链接有效性再决定要不要补跑，避免做无用功；
第二个坑是空文件的处理，比如那个0KB的readme.txt，一开始没注意，后来整理的时候才发现，不仅占了一个文件名，后续如果做文件去重的话还会被误判成重复文件，直接清理掉就行。

写在最后

这次任务虽然不大，但踩的坑其实很典型：很多开发者在处理批量任务的时候，遇到中断第一反应是全量重跑，反而浪费更多时间。最后总结3个可带走的方法：

1. 后台任务中断后先截取输出日志做完整性校验，区分「跳过」「失败」「成功」三类状态，再决定是补跑还是重跑，别盲目全量重跑；
2. 批量文件下载后先按业务维度分类，再处理重复/空文件，从根源降低后续的检索、处理成本；
3. 遇到资源下载失败的场景，先校验资源本身的有效性，再决定补跑策略，避免做无用功。