不能直接读大文件进内存算MD5，因会触发OOM或系统卡死；必须用OpenSSL的EVP_MD_CTX分块流式计算，严格遵循初始化、增量更新、最终收尾三步铁律，确保状态正确、内存安全、结果准确。
大文件直接读进内存算 MD5 必然崩，不是 std::bad_alloc 就是卡死；必须用 OpenSSL 的 EVP_MD_CTX 分块流式更新状态，且每一步的初始化、喂数据、收尾都不可省略或错序。
为什么不能用 std::ifstream::read 一次性加载再哈希
几十 GB 的镜像或数据库快照会瞬间吃光堆内存，std::bad_alloc 是最温和的结果；更常见的是系统开始疯狂 swap，UI 卡死，甚至触发 OOM killer 杀掉你的进程。MD5 算法本身支持分块输入——它只维护一个 128 位内部状态，每次处理 64 字节并更新该状态。关键不是“能不能分”，而是“怎么分得不丢字节、不越界、不漏错误”。
-
file.read(buf, size)返回值不反映真实读取字节数，必须立刻读file.gcount() -
while (!file.eof())是经典陷阱：最后一次读失败后仍会进入循环一次，导致用 0 字节调用EVP_DigestUpdate() -
seekg(0, std::ios::end)+tellg()测文件大小在管道、设备文件（如/dev/urandom）、NFS 挂载点上直接返回 -1，完全不可靠
用 EVP_MD_CTX 做流式 MD5 的三步铁律
EVP_MD_CTX 不是 POD 类型，不能栈上声明、不能复用、不能跳过释放。OpenSSL 1.1.1+ 强制要求用工厂函数管理生命周期，任何偷懒都会导致内存泄漏或后续 segfault。
- 必须用
EVP_MD_CTX_new()分配，绝不用new EVP_MD_CTX或栈变量 - 初始化必须调
EVP_DigestInit_ex(ctx, EVP_md5(), nullptr)，第三个参数传nullptr，传NULL在某些平台有未定义行为 - 每次
EVP_DigestUpdate()后检查返回值是否为 1；非 1 表示失败（比如buf为nullptr或长度为负） - 结束必须调
EVP_DigestFinal_ex()，只靠EVP_DigestUpdate()无法完成 padding 和最终状态翻转，结果一定错 - 所有出错路径（文件打不开、初始化失败、更新失败）都必须调
EVP_MD_CTX_free(ctx)，建议用 RAII 封装或 goto cleanup
std::ifstream 分块读取的实操细节
缓冲区大小不是越大越好，也不是越小越安全。8192 字节（8KB）是机械盘、SSD、NVMe 上实测吞吐与驻留内存占用的平衡点。Windows text 模式会把 \r\n 自动转成 \n，哈希值彻底错乱，必须显式指定 std::ios::binary。
立即学习“C++免费学习笔记（深入）”；
- 用
std::vector<char> buf(8192)</char>预分配，避免反复new/delete开销 - 循环条件写成
while (file.read(buf.data(), buf.size()) || file.gcount() > 0)，确保末块不满时仍能进入 -
file.gcount()必须在每次read()后**立刻**读取，下一次read()会覆盖它 - 若
file.fail()且!file.eof()，说明发生 I/O 错误（权限不足、磁盘坏道等），应立即终止并检查file.rdstate() - Linux 下
read()可能被信号中断（errno == EINTR），需重试；但std::ifstream封装层不暴露 errno，所以依赖gcount()+fail()组合判断更稳妥
生成最终 MD5 字符串的转换要点
OpenSSL 输出的是 16 字节原始二进制摘要（unsigned char digest[16]），不是字符串。转成标准 32 字符小写十六进制字符串时，容易忽略大小写和填充格式。
- 必须转小写 hex，不能用
std::hex直接输出到std::stringstream（默认无前导零、大小写不控） - 推荐手动查表或用
std::format("{:02x}", byte)（C++20）；C++17 及之前可用sprintf或std::setfill('0') + std::setw(2) - 别忘了
EVP_MD_size(EVP_md5())返回 16，硬编码数组大小虽可行，但换算法（如 SHA256）就失效 - Windows 静态链接 OpenSSL 时，即使只算 MD5，也必须额外链接
ws2_32.lib，否则链接失败（符号如WSAStartup会被拉进来）
最易被忽略的其实是错误分支的资源清理——EVP_MD_CTX_free() 漏掉一次，在小文件测试中几乎看不出问题；但跑几小时批量校验任务后，mmap: Cannot allocate memory 就会突然报给你看。状态对象的生命期必须和数据流严格对齐，差一个 free，整个流程就不算完整。
