不能一次性读大文件算md5，因易触发std::bad_alloc或系统卡死；必须用openssl的evp_md_ctx分块流式计算，严格遵循初始化、增量更新、最终收尾三步，确保状态正确、内存安全、结果准确。
直接用 std::ifstream::read 一次性读整个大文件进内存算 MD5，99% 会触发 std::bad_alloc 或让系统卡死；真正高效的做法是用 OpenSSL 的 EVP_MD_CTX 分块流式更新哈希状态，缓冲区大小、错误重试、二进制模式缺一不可。
为什么不能跳过 EVP_MD_CTX 直接喂数据
MD5 是分块迭代算法（每 64 字节更新一次内部 128 位状态），但标准库不提供增量接口。手写 RFC 1321 实现极易出错：字节序错、padding 漏补、final 逻辑缺失都会导致结果偏差。OpenSSL 的 EVP_MD_CTX 封装了全部细节，且经多年生产验证——它不是“可选”，而是事实标准。
-
EVP_MD_CTX必须用EVP_MD_CTX_new()创建，栈上声明或复用未重置的实例会导致内存泄漏或 segfault - 每次
EVP_DigestUpdate()可传任意长度（哪怕 1 字节），内部自动缓存未满块；但漏掉最后的EVP_DigestFinal_ex()，结果就永远不完整 - 多线程环境下，每个线程必须独占一个
ctx，不能共享或跨线程传递
缓冲区大小选 8192 还是 65536
这不是玄学，而是 I/O 路径与缓存行为的权衡。实测在本地 ext4 + SSD 上，65536（64KB）比 8192（8KB）吞吐高不到 3%，但某些 NFS 或容器挂载场景下，64KB 反而因内核页缓存压力升高而变慢。
- 本地磁盘（SSD/NVMe）：优先用
65536，接近多数文件系统默认块大小，减少系统调用次数 - 网络存储、容器卷、不确定环境：回落到
8192，更保守，避免read()返回 -1 或部分填充时处理复杂 - 绝对别用
std::vector<char>(filesize)</char>预分配——这是典型反模式，小文件测不出问题，大文件跑久了直接mmap: Cannot allocate memory
如何安全读取并处理中断和 EOF
std::ifstream::read() 返回值不反映真实读取字节数，而 while (!file.eof()) 是经典陷阱：最后一次读失败后仍会进入循环一次，导致用 0 字节调用 EVP_DigestUpdate()，污染哈希状态。
- 必须立刻检查
file.gcount()，它才表示本次read()真实读入的字节数 - 循环条件应为
while (file.read(buf, size) || file.gcount() > 0)，确保末块不满时仍能进入 - 若
file.fail()且!file.eof()，说明发生 I/O 错误（权限不足、磁盘坏道等），应立即终止并返回file.rdstate() - Linux 下
read()可能被信号打断，返回 -1 且errno == EINTR；此时需重试，fread()不暴露 errno，推荐用底层read()+while (n == -1 && errno == EINTR)循环兜底
生成最终 MD5 字符串时最容易忽略的点
EVP_DigestFinal_ex() 输出的是 16 字节二进制数据，里面可能含 \0，直接当 C 字符串打印会截断或乱码。OpenSSL 不提供自动转 hex 的函数，这一步必须手动处理。
- 别用
std::to_string()——它转整数，不是字节的十六进制表示 - 推荐用
std::ostringstream+std::hex+std::setw(2)+std::setfill('0')，安全且无缓冲区溢出风险 - 若用 C 风格，
sprintf(hex + i * 2, "%02x", md[i])要确保hex缓冲区至少预留 33 字节（32 字符 +\0） - Windows 上若用文本模式打开文件，
\r\n会被自动转成\n，哈希值彻底错乱，必须显式指定std::ios::binary
最常被忽略的其实是上下文生命周期管理：所有出错路径（文件打不开、EVP_DigestInit_ex() 失败、EVP_DigestUpdate() 中断）都必须调 EVP_MD_CTX_free(ctx)，否则小文件看不出问题，大文件长期运行会内存耗尽。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
