必须分块流式读取并增量哈希，因一次性加载大文件易触发bad_alloc或系统卡顿；seekg+tellg测大小在管道、设备文件等场景不可靠，应以gcount()为准；EVP_MD_CTX需严格配对初始化与释放，缓冲区须binary模式且大小适中（64KB–1MB），哈希结果须转小写十六进制字符串。
直接用 std::ifstream::read 一次性加载大文件进内存再喂给哈希函数，99% 会触发 std::bad_alloc 或拖慢整个系统；必须分块流式读取 + 增量调用 EVP_DigestUpdate，且所有环节都要对齐字节序、缓冲区生命周期和错误分支清理。
为什么不能用 std::ifstream::seekg(0, std::ios::end) 算大小再分配内存
这个操作在管道、设备文件（如 /dev/urandom）、NFS 挂载点或 Windows 的某些重定向句柄下直接失败，tellg() 返回 -1；即使成功，file_size() 也只反映 stat() 时刻的长度，文件可能被截断或追加，导致后续 read() 实际字节数 != 预期，进而漏数据或越界访问。
- 永远以
file.gcount()为准——它返回本次read()真实读到的字节数，末块不满缓冲区时尤其关键 - 不要依赖
!file.eof()控制循环：它只在读失败后置位，容易多算一次空循环 - 若需预估进度（如 UI 进度条），可用
std::filesystem::file_size(path)作参考，但绝不用于内存分配
EVP_MD_CTX 的初始化、更新与释放必须严格配对
EVP_MD_CTX 是有状态对象，不是 POD 类型；OpenSSL 1.1.1+ 强制要求用 EVP_MD_CTX_new() 分配，用 EVP_MD_CTX_free() 释放。漏掉任意一个 free 都会泄漏 OpenSSL 内部堆内存；提前 return 时没 free 更会导致后续调用 segfault。
- 初始化必须用
EVP_DigestInit_ex(ctx, md, nullptr)，第三个参数传nullptr表示默认 engine；传NULL（C 风格空指针）在某些平台会 UB - 每次
EVP_DigestUpdate()后检查返回值：非 1 表示失败（常见于buf为nullptr或len为负） - 所有出错路径（
!file.is_open()、EVP_DigestInit_ex失败、EVP_DigestUpdate失败）都必须调EVP_MD_CTX_free(ctx)，建议用 RAII 封装或 goto cleanup
缓冲区大小选 64KB–1MB，且必须用 std::ios::binary 打开
缓冲区太小（如 1KB）会让系统调用频次飙升，read() 开销压过哈希计算；太大（如 16MB）则浪费内存驻留，还可能挤占页缓存影响其他 IO。Windows text 模式下会把 \r\n 自动转成单个 \n，哈希值彻底错乱，必须显式指定 std::ios::binary。
立即学习“C++免费学习笔记（深入）”；
- 推荐
std::vector<uint8_t> buf(65536)</uint8_t>—— 对齐常见页大小，兼顾吞吐与内存友好 -
file.read(reinterpret_cast<char>(buf.data()), buf.size())</char>后立刻用file.gcount()获取真实长度，别假设等于buf.size() - 循环末尾要单独处理
if (file.gcount() > 0) { EVP_DigestUpdate(...); }，否则最后一块丢失
输出哈希值必须转小写十六进制字符串，不能直接打印二进制
16 字节 MD5 或 32 字节 SHA256 结果是纯二进制数据，含 \0 和不可见控制符；用 printf("%x") 或 std::string(digest, len) 会截断或乱码，且无法保证前导零和大小写统一。
- 逐字节转十六进制：用
std::stringstream+std::hex/std::setw(2)/std::setfill('0')，确保每字节输出两位、小写、补零 - 别用
sprintf_s或手写查表——易出边界，且 C++20 前无标准安全替代 - 验证是否正确：生成结果必须和命令行
md5sum file.bin或sha256sum file.bin输出完全一致（不含空格、不含filename:前缀）
最常被忽略的是 gcount() 的调用时机和 EVP_MD_CTX_free() 的全覆盖——这两个点出错，程序可能在 99% 的文件上都正常，唯独在末块不满、或打开失败时静默崩溃或返回空字符串。
