应使用OpenSSL的EVP_MD_CTX分块计算文件MD5，因大文件一次性读入内存会触发std::bad_alloc或卡死；需以8192字节缓冲区流式读取、检查gcount()真实字节数、调用EVP_DigestInit_ex/EVP_DigestUpdate/EVP_DigestFinal_ex三步完整流程，并及时释放ctx。
为什么不能直接读整个文件进内存算 MD5
因为大文件（比如几个 GB 的视频或数据库快照）会触发 std::bad_alloc，或者让程序响应卡死。标准库的 std::md5（C++23）根本不支持增量输入，而 OpenSSL 的 EVP_MD_CTX 或 Boost.Hash 都要求你手动分块喂数据——关键不是“能不能”，而是“怎么喂得既安全又不丢字节”。
用 OpenSSL EVP 接口做流式 MD5 的正确姿势
OpenSSL 是最常用也最稳妥的选择，但容易在初始化、更新、结束三步中漏掉关键检查。尤其是多线程环境下，EVP_MD_CTX 必须每个线程独占，不能复用未重置的上下文。
- 每次计算前必须调用
EVP_MD_CTX_new()，别用栈上分配的旧结构体 - 读文件时用固定大小缓冲区（推荐
8192字节），避免read()返回值为 0（EOF）或 -1（错误）时仍调用EVP_DigestUpdate() - 最后一定要调用
EVP_DigestFinal_ex()，而不是只靠EVP_DigestUpdate()—— 否则哈希值不完整，末尾填充（padding）没生效 - 别忘了
EVP_MD_CTX_free()，否则小文件测不出泄漏，大文件跑久了会mmap: Cannot allocate memory
unsigned char hash[EVP_MD_size(EVP_md5())];
unsigned int hash_len;
EVP_MD_CTX *ctx = EVP_MD_CTX_new();
EVP_DigestInit_ex(ctx, EVP_md5(), nullptr);
std::ifstream file("huge.bin", std::ios::binary);
char buf[8192];
while (file.read(buf, sizeof(buf)) || file.gcount() > 0) {
size_t n = file.gcount();
EVP_DigestUpdate(ctx, buf, n);
}
EVP_DigestFinal_ex(ctx, hash, &hash_len);
EVP_MD_CTX_free(ctx);
处理 mmap 失败或 read() 被信号中断的边界情况
Linux 下读超大文件时，read() 可能返回 -1 并设 errno == EINTR；而 mmap() 在物理内存不足时直接失败。流式计算必须容忍这些，不能假设每次 read() 都成功填满缓冲区。
- 检查
file.gcount()而非file.read()的返回值，它才反映真实读入字节数 - 若
file.fail()但!file.eof()，说明出错（如权限问题或磁盘 I/O 错误），应立即终止并报file.rdstate() - 不要用
while (!file.eof())—— 它会在最后一次读失败后仍进入循环一次，导致重复喂空数据
MD5 值输出成十六进制字符串的常见错位
很多人把 hash[0] 当作高位字节直接转 hex，结果得到反序结果（比如正确是 "d41d8cd9..."，却输出 "...d98cd1d4"）。MD5 标准输出是大端序字节流，数组下标 0 就是第一个字节，不需要反转。
- 逐字节用
printf("%02x", hash[i])或std::format("{:02x}", hash[i])（C++20） - 避免用
std::hex —— 若没加std::setw(2) ，单字节0xf会输出成"f"而非"0f" - 如果要用
std::string拼接，记得 reserve(32)，避免频繁 realloc
实际中最容易被忽略的是：文件末尾有 \0 字节或换行符时，是否该参与哈希？答案是**必须参与**——MD5 是对原始字节流的全量摘要，任何跳过、截断、trim 都会导致校验失败。哪怕只是用 std::getline() 读文本文件，也会丢掉换行符，彻底破坏哈希一致性。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
