云盘批量下载突遭进程终止？我用这套方法10分钟完成全部文件校验整理

引言

上周需要批量下载一批古籍、命理资料和经典文学电子书，总大小接近200G，我写了个Python脚本对接云盘批量下载接口，开在服务器后台跑。结果跑了大概3个小时，回来发现进程已经被系统发了SIGTERM强制终止，屏幕上只留下一半的下载日志，瞬间慌了：不知道哪些文件下完了，哪些下了一半，重跑的话怕重复下载触发云盘限流，不重跑又怕漏了资源。
就是在这堆乱糟糟的日志里，我摸索出了一套批量下载中断后的校验整理方法，10分钟就理清了所有文件的状态，还顺便优化了脚本的健壮性。

---

第一步：先拉全量日志，做状态初筛

首先不要急着重新跑下载任务，先把中断前的完整下载日志拉出来——我当时从进程的输出缓冲里捞到了最后1978字符的日志，里面已经明确标记了每个文件的下载状态：✅代表成功，❌代表失败。
先把所有条目按状态分类：成功条目包含《天星阳宅》梁承浩抄本.pdf、《阴基、阳宅风水资料》.pdf、《梅花易数》射覆浅谈.pdf等20余个文件，还有个0KB的readme.txt，后来确认是云盘里本身存在的空文件，属于正常情况；失败条目只有1个：小王子.txt，标注是「无链接」，属于资源本身缺失，不需要重试；还有我的应用/目录下的Tor浏览器安装包，日志里标记了成功，但需要单独校验完整性。
这里踩的第一个坑是：一开始我以为日志里的✅就代表万无一失，后来才发现有个别带特殊字符的文件名（比如《民间风水秘术》后六章存稿！.docx、公笃相法（千相老师精华校订版）(1).pdf），在终端显示的时候容易出现编码乱码，手动核对很容易漏，所以初筛之后必须做双向校验。

---

第二步：双向校验，排除“假成功”

初筛之后，我写了不到10行的Python脚本做双向比对：一边是日志里提取的所有成功文件名，另一边是本地下载目录的实际文件列表，自动计算差集。
比对结果很清晰：除了已经确认的0KB空文件和缺失资源，剩下的成功文件全部和本地文件匹配，没有遗漏也没有多余的文件。针对那个169MB的Tor安装包，我额外拉了云盘端的文件MD5和本地文件的MD5做了比对，完全一致，确认是完整下载的。
这里踩的第二个坑是：一开始我手动数日志里的成功条目，数了三遍都怕漏，后来用脚本自动比对，不仅速度快，还能自动识别编码问题——比如那个带中文括号和感叹号的文件名，脚本用UTF-8解码之后能正确识别，不会因为终端显示乱码被漏掉。

---

第三步：整理归档，给后续任务留“活口”

校验完成之后，我把所有文件按类型整理到了不同的目录：古籍风水类、命理紫微类、经典文学类、应用安装包类，同时生成了一个download_manifest.json清单文件，记录了每个文件的名称、大小、MD5、下载状态。
这个清单后来成了“神器”：之后如果需要增量下载同目录下的其他资源，只需要拉云盘端的最新文件列表，和这个清单做比对，就能直接知道哪些是已经下过的，哪些是新增的，不用再重新跑全量下载，也避免了重复下载触发限流。
另外我还给下载脚本加了信号捕获逻辑：就算再被系统发SIGTERM终止，也会自动把当前下载进度和已完成的文件列表写到日志里，下次启动的时候可以直接从断点处继续，不用从头开始。

---

结尾：可带走的方法论

这次踩坑其实总结下来就是三个核心动作，不管是云盘下载还是其他批量资源采集场景都能用：

1. 永远不要信“进度条”，只信“状态日志”：批量任务一定要输出明确的成功/失败状态标记，不要只看整体进度，中断后先拉全量日志做初筛；
2. 双向校验比“感觉”靠谱：日志里的成功标记和本地实际文件要做双向比对，特殊字符文件名一定要做编码校验，避免漏判；
3. 多花5分钟做归档，省下50分钟返工：下载完成后顺手生成文件清单，后续增量任务直接复用，比每次重新跑全量效率高得多。
   如果是云盘批量下载的场景，优先选自带断点续传、文件校验功能的官方工具或者成熟第三方工具，比自己写脚本省心太多，毕竟稳定性和兼容性已经经过大量用户验证了。