应流式分块计算MD5，避免内存溢出；推荐8KB缓冲区、OpenSSL的EVP_MD_CTX增量接口，正确调用EVP_DigestFinal_ex，十六进制输出需补前导零。
为什么不能直接读整个文件进内存算MD5
大文件（比如几个GB的视频或镜像）直接用 std::ifstream::read 一次性加载，会触发内存溢出或系统拒绝分配——这不是算法问题，是资源管理问题。MD5本身只处理512位分组，必须流式喂数据，且每次喂入的缓冲区大小直接影响I/O效率和CPU缓存命中率。
- 典型错误：用
std::filesystem::file_size分配等大内存再读，std::bad_alloc立刻报错 - 安全缓冲区尺寸：8192 字节（8KB）是多数文件系统块大小的整数倍，能减少系统调用次数
- 别用
std::string中间拼接，避免多次内存重分配；直接用固定大小的std::array<uint8_t></uint8_t>或裸char buf[8192]
用 OpenSSL 的 EVP_MD_CTX 增量计算 MD5
OpenSSL 提供标准、稳定、已优化的增量哈希接口，比手写MD5轮函数靠谱得多，且支持多平台编译。关键是正确初始化、分块更新、最终获取摘要——漏掉 EVP_DigestFinal_ex 就永远得不到结果。
- 必须调用
EVP_MD_CTX_new()创建上下文，不能栈上声明EVP_MD_CTX结构体 - 每次
EVP_DigestUpdate(ctx, buf, bytes_read)后不检查返回值，遇到磁盘错误会静默失败 - 摘要输出长度固定为16字节，但常需转成32字符十六进制字符串：
std::ostringstream或手动查表更快
EVP_MD_CTX* ctx = EVP_MD_CTX_new();
EVP_DigestInit_ex(ctx, EVP_md5(), nullptr);
while ((n = file.readsome(buf, sizeof(buf))) > 0) {
EVP_DigestUpdate(ctx, buf, n);
}
unsigned char md[MD5_DIGEST_LENGTH];
unsigned int len;
EVP_DigestFinal_ex(ctx, md, &len); // 必须调用！
Windows下用 CreateFile + ReadFile 避免C++流开销
在Windows上，std::ifstream 默认启用缓冲并做额外的locale/codecvt处理，对纯二进制大文件反而拖慢。直接调用WinAPI可绕过这些，尤其配合 FILE_FLAG_NO_BUFFERING（需对齐到扇区边界）能进一步提速，但开发时慎用——调试困难且移植性归零。
- 打开文件必须加
GENERIC_READ和FILE_SHARE_READ，否则其他进程无法同时读 -
ReadFile返回0不一定是EOF：要检查GetLastError() == ERROR_HANDLE_EOF - 缓冲区地址和大小都必须是磁盘扇区对齐（通常512字节），否则
FILE_FLAG_NO_BUFFERING直接失败
输出32位小写十六进制字符串时别用 std::hex 默认格式
std::hex 默认不补前导零、不固定宽度，16字节摘要里单字节值如 0x7 会变成 "7" 而非 "07"，导致最终字符串只有31位甚至更短——MD5校验必然失败。
立即学习“C++免费学习笔记（深入）”；
- 推荐用静态查表法：预定义
const char hex_chars[] = "0123456789abcdef"，循环转换每个字节 - 若用
std::ostringstream，必须设std::setw(2) ，且每次写入一个字节 - 别返回
std::string拼接中间结果，直接写入目标std::array<char></char>更高效
实际跑通的关键不在算法本身，而在缓冲区对齐、错误码检查、十六进制补零这三个地方——少一个，算出来的MD5就和 certutil -hashfile 或 md5sum 对不上。
