断点续传本地分片MD5校验失败的根本原因是最后一片读取时边界处理不当，导致字节长度偏差；需严格按“起始偏移+长度”读取、用gcount()校验实际读取字节数、将本地MD5转小写hex字符串后比对服务端hex值。
为什么断点续传里本地分片 MD5 校验总对不上
根本原因不是算法写错了，而是分片读取时没处理好边界和字节对齐——尤其是最后一片，容易多读或少读几个字节，导致 MD5 值和服务器下发的校验值不一致。常见现象是：前 N-1 片全对，唯独最后一片 MD5 不匹配，但用 md5sum 手动算整个文件又完全正确。
- 分片逻辑必须严格按「起始偏移 + 长度」读取，不能用
std::ifstream::seekg后靠read返回值判断是否读满——它可能因 EOF 提前返回，导致实际读取长度 expected_size - 务必用
gcount()检查真实读取字节数，并只对这gcount()字节计算MD5，而不是对整个缓冲区 - 如果分片大小不是 4KB/64KB 这类整数倍，且文件长度不能被整除，最后一片长度一定 ≠ 其他片，硬编码固定片长去算 MD5 必然错
用 OpenSSL 的 EVP_MD_CTX 增量计算分片 MD5（C++）
别把整片 load 到内存再算——大文件（比如 2GB 分片）会触发 OOM；要用流式增量哈希。OpenSSL 的 EVP_MD_CTX 是最稳妥的选择，Windows/macOS/Linux 全平台可用，比手撸 MD5 或依赖 Boost 更轻量。
- 初始化用
EVP_MD_CTX_new()，别用栈上EVP_MD_CTX变量——OpenSSL 1.1+ 要求堆分配 - 每次
EVP_DigestUpdate()前确认传入的len是真实读取字节数（即is.gcount()），不是缓冲区大小 - 计算完立刻调
EVP_MD_CTX_free()，否则泄漏；同一 ctx 不能跨分片复用，每个分片必须新建+销毁
unsigned char md_value[EVP_MAX_MD_SIZE]; unsigned int md_len; EVP_MD_CTX* ctx = EVP_MD_CTX_new(); EVP_DigestInit_ex(ctx, EVP_md5(), nullptr); EVP_DigestUpdate(ctx, buf, static_cast<size_t>(bytes_read)); // bytes_read = is.gcount() EVP_DigestFinal_ex(ctx, md_value, &md_len); EVP_MD_CTX_free(ctx);
std::ifstream 分片读取必须用 std::ios::binary 和 is.clear()
文本模式下 Windows 会把 \r\n 自动转成 \n，直接破坏二进制一致性；而断点续传任何环节都要求原始字节完全一致。更隐蔽的坑是：多次 seekg 后，流状态可能置 failbit，后续 read 直接跳过不执行，但你不检查 is.good() 就以为读成功了。
- 打开文件必须加
std::ios::binary：std::ifstream is(path, std::ios::binary) - 每次
seekg(offset)后，立刻调is.clear()清除潜在错误标志 -
read()后必须检查is.gcount() > 0，而不是只看is.good()——因为read到 EOF 时good()为 false，但gcount()仍返回有效字节数
服务端下发的分片 MD5 怎么和本地比对才可靠
别直接 strcmp 二进制摘要——服务端大概率返回的是 hex 字符串（如 "a1b2c3..."），而你算出来的是 raw bytes。两者格式不一致，比对必然失败。另外注意大小写：RFC 不强制 hex 大小写，但 OpenSSL 输出默认小写，若服务端返回大写 hex，直接 memcmp 会误判。
立即学习“C++免费学习笔记（深入）”；
- 本地算完 raw
MD5后，先转成小写 hex 字符串再比对（用sprintf或std::format，避免手写循环） - 比对前统一 trim 空格、换行符——HTTP header 或 JSON 字段里可能混入不可见字符
- 如果服务端给的是 base64 编码的摘要（少见但存在），必须先
BIO_f_base64()解码，再和 rawMD5比，不能和 hex 字符串比
最后一片的长度计算、gcount() 检查、hex 编码统一小写——这三个点只要漏一个，MD5 校验就失效。没人会专门告诉你“seekg 后要 clear”，但它真会静默让你的续传校验永远卡在最后一片。
