如何用C++稳健地计算大文件的MD5哈希值？
直接使用 std::ifstream 将整个文件读入内存再计算MD5，对于大文件（例如超过1GB）来说，无异于一场“内存灾难”——要么内存溢出，要么直接触发系统的OOM杀手。稳妥的做法，必须是分块读取文件，并配合加密库进行增量哈希更新。
加密库选择：为何首选OpenSSL的EVP接口？
自己实现MD5算法既容易出错，也非必要；而OpenSSL中旧的 MD5_Init/MD5_Update 系列函数也已被弃用。当前（OpenSSL 1.1.1及以上版本）的行业最佳实践是使用 EVP_MD_CTX 配合 EVP_md5()。这套接口天生为流式计算设计，每个上下文线程安全，并且跨平台编译的稳定性久经考验。
- 只需包含一个头文件：
openssl/evp.h - 链接时记得加上
-lssl -lcrypto（Linux/macOS）或对应的Windows库文件 - 开发者无需手动管理MD5的状态数组，
EVP_DigestUpdate会自动处理数据块边界和最终的填充（padding）
分块大小如何设定？8KB是经验上的“甜点”
块大小设置是个平衡艺术：太小（比如512字节）会导致频繁的系统调用和CPU缓存效率低下；太大（比如1MB）则可能耗尽小内存设备的剩余资源，且对速度提升帮助有限。经过在不同存储介质（机械硬盘、SSD、NVMe）上的实测，8192字节（即8KB）通常在吞吐量和稳定性上表现最佳。
- 建议使用
std::vector预分配内存，避免循环中反复申请释放buffer(8192) - 读取时调用
file.read(buffer.data(), buffer.size())，并通过file.gcount()获取实际读取的字节数 - 放心，即使最后一块数据不足8KB，
EVP_DigestUpdate也能正确处理
完整步骤拆解：从打开文件到输出哈希字符串
整个流程的核心在于理解调用顺序：EVP_DigestFinal_ex 只能调用一次，且必须发生在所有 EVP_DigestUpdate 完成之后。该函数输出的是16字节的原始摘要，需要手动转换为32位小写的十六进制字符串。
立即学习“C++免费学习笔记（深入）”；
EVP_MD_CTX* ctx = EVP_MD_CTX_new();
EVP_DigestInit_ex(ctx, EVP_md5(), nullptr);
std::ifstream file("input.bin", std::ios::binary);
std::vector buf(8192);
while (file.read(buf.data(), buf.size()) || file.gcount() > 0) {
EVP_DigestUpdate(ctx, buf.data(), file.gcount());
}
unsigned char digest[EVP_MD_size(EVP_md5())];
unsigned int len;
EVP_DigestFinal_ex(ctx, digest, &len); // len == 16
// 转换为十六进制字符串：可使用 sprintf_s / std::format(C++20) / 手动查表
EVP_MD_CTX_free(ctx);
- 资源管理：忘记调用
EVP_MD_CTX_free会导致OpenSSL内部资源泄漏 - 读取细节：
file.gcount()必须在每次read()操作后立即使用，否则下一次读取会覆盖其值 - 路径处理：在Windows下，若文件路径包含中文，需使用
std::wifstream配合_wfopen，但注意OpenSSL接口通常只接受UTF-8编码的路径，可能需要预先转换
实际开发中，真正容易踩坑的往往是错误处理环节：OpenSSL函数返回0表示失败，但不会抛出异常；判断文件读取状态时，结合 file.fail() 和 file.eof() 比单独检查 eof() 更可靠；如果使用 sprintf 进行十六进制转换，务必确保目标缓冲区至少为33字节（32字符 + 1个空终止符）。把这些细节做到位，代码的健壮性才有保障。
