不能直接读整个文件进内存算MD5，因为会触发OOM或系统卡死；MD5算法支持分块输入，内部维护128位状态向量，每次处理512位数据并更新状态，可通过OpenSSL的EVP_DigestUpdate实现流式增量计算。
为什么不能直接读整个文件进内存算MD5
超大文件（比如几十GB的镜像或视频）一上来就 fread 全部内容，大概率触发 OOM 或系统卡死。MD5 算法本身支持分块输入——它内部维护一个 128 位的状态向量（state[4]），每次处理 512 位（64 字节）数据并更新该状态。只要按块喂数据、不重置状态，就能累积计算。
用 OpenSSL 的 EVP_MD_CTX 做流式 MD5 更新
别自己实现 MD5 循环逻辑，OpenSSL 提供了标准、安全、已优化的接口。关键不是“一次性哈希”，而是用 EVP_DigestUpdate 多次追加数据。
实操要点：
- 调用
EVP_MD_CTX_new()创建上下文，再用EVP_DigestInit_ex(ctx, EVP_md5(), nullptr)初始化 - 打开文件后，用固定缓冲区（如
std::vector<uint8_t>(64 * 1024)</uint8_t>）循环fread，每读一块就调用EVP_DigestUpdate(ctx, buf.data(), n) - 读完后调用
EVP_DigestFinal_ex(ctx, md, &md_len)获取最终 16 字节结果 - 务必检查每次
fread的返回值是否等于请求长度（处理磁盘 I/O 中断或 EOF 提前）
增量更新：如何复用已有哈希值继续计算
所谓“增量更新”，本质是跳过已处理部分，从某个偏移开始续算。但 MD5 不支持随机跳转——你不能只给它“后面那段数据”就得出完整哈希。必须从头开始，或保存中间状态。
立即学习“C++免费学习笔记（深入）”；
可行做法：
- 若业务允许，把文件切分成固定大小块（如 1MB），分别计算每块的 MD5，再对所有块哈希拼接后二次哈希（类似 Merkle 树思想）
- 若必须单 MD5 且支持断点续算，需在上次计算结束时调用
EVP_MD_CTX_copy_ex()保存完整上下文（含state、num、data等），序列化到磁盘；下次加载该上下文，再继续EVP_DigestUpdate -
EVP_MD_CTX不可直接 memcpy —— 必须用EVP_MD_CTX_copy_ex拷贝，否则内部指针失效
性能与边界注意点
缓冲区大小直接影响吞吐：太小（如 1KB）导致 syscall 过多；太大（如 1MB）未必提升，还占内存。实测 64KB–256KB 是多数 Linux/NTFS 下较优区间。
容易踩的坑：
- 忘记在
EVP_DigestFinal_ex后调用EVP_MD_CTX_free→ 内存泄漏 - 用
std::ifstream默认构造 +read()，未设std::ios::binary→ Windows 下遇到\r\n被截断，哈希错 - 文件末尾不足 64 字节时，OpenSSL 自动 padding（按 MD5 规范补
0x80 0x00...+ 长度），无需手动处理，但你自己实现 padding 就极易出错 - 32 位程序读 >4GB 文件需用
fseeko/off_t和编译选项（如-D_FILE_OFFSET_BITS=64），否则fseek可能回绕
最麻烦的其实是跨平台文件长度判断和中断恢复逻辑，而不是 MD5 本身。状态持久化格式、校验机制、并发访问保护，这些才是真实项目里卡住进度的地方。
