断点续传必须校验本地分片MD5，因网络中断、磁盘异常或崩溃可能导致分片不完整；需用OpenSSL流式计算并比对十六进制摘要，注意上下文重置、路径一致性和落盘同步。
为什么断点续传必须校验本地分片的 MD5？
因为网络中断、磁盘写入异常或程序崩溃后，恢复下载时无法信任已写入磁盘的分片文件是否完整——哪怕大小一致，末尾几个字节可能被截断或写错。MD5 是最轻量且广泛支持的完整性校验手段，比对本地分片的 MD5 和服务端下发的分片摘要，能快速发现损坏或不一致的块，避免续传错误数据。
用 C++ 读取大文件分片并计算 MD5 的正确姿势
别直接把整个分片读进内存（尤其几百 MB 的分片），要用流式分块计算；C++ 标准库不带 MD5，得依赖 OpenSSL 或自己实现简易版。推荐用 OpenSSL 的 EVP_DigestUpdate 接口，稳定且支持增量计算。
- 打开文件用
std::ifstream，设为std::ios::binary模式，否则 Windows 下会误判换行符 - 每次读
8192字节（或64*1024）进缓冲区，调用EVP_DigestUpdate累加哈希，而不是一次性read全部 - 务必检查
gcount()返回值，防止最后一块读不满却仍参与计算 - 别用
std::filesystem::file_size做分片边界判断——它可能不准（如 ext4 的延迟分配），应以实际read字节数为准
unsigned char md5_result[MD5_DIGEST_LENGTH];
MD5_CTX ctx;
MD5_Init(&ctx);
std::ifstream ifs("part_001.bin", std::ios::binary);
char buf[8192];
while (ifs.read(buf, sizeof(buf))) {
MD5_Update(&ctx, buf, ifs.gcount());
}
if (ifs.gcount() > 0) {
MD5_Update(&ctx, buf, ifs.gcount());
}
MD5_Final(md5_result, &ctx);
如何安全比对本地分片 MD5 和服务端摘要？
服务端通常返回十六进制字符串（如 "a1b2c3..."），而本地算出的是二进制字节数组，直接 memcmp 容易出错；且要防“空文件”或“零长度分片”的边界情况。
- 先确认分片文件存在且大小非零，再启动计算；大小为 0 时直接视为校验失败（除非服务端明确允许空分片）
- 将本地
md5_result转成小写十六进制字符串，和服务器返回的摘要做std::equal比较，别用strcmp（可能含 \0） - 服务端摘要若带
"md5:"前缀（如"md5:a1b2c3..."），需先剥离再比对 - 不要在比对前把摘要转大写——OpenSSL 默认输出小写，大小写混用会导致误判
容易被忽略的三个坑
这些点不报错，但会让断点续传“看起来成功”，实则后续合并失败或文件损坏：
立即学习“C++免费学习笔记（深入）”；
- 没清空
MD5_CTX就复用——多个分片连续计算时，忘记调用MD5_Init重置上下文，导致哈希值累加污染 - 分片路径拼接出错，比如用
std::to_string(index)生成"part_0.bin"，但服务端编号从 1 开始，结果校验了不存在的文件 - 没处理文件系统缓存：Linux 下频繁小块读写后，
stat()可能返回过期 size，建议在计算 MD5 前加fsync或fdatasync（仅限已 close 的 fd）确保落盘
校验逻辑本身不复杂，难的是和下载状态机、文件锁、路径管理这些环节咬合严实——一个分片的 MD5 算错，整个续传链就断在看不见的地方。
