应分块流式读取并增量哈希更新，因一次性加载大文件易致OOM或卡死；必须用std::ios::binary模式、检查gcount()、正确初始化/清理EVP_MD_CTX，并将32字节哈希转为小写十六进制字符串。
直接用 std::ifstream::read 一次性读完整个大文件再喂给 SHA256，大概率会 OOM 或卡死——这不是算法慢，是内存用错了地方。必须分块流式读取 + 增量哈希更新。
为什么不能用 ComputeHash 或全量 read
OpenSSL 的 EVP_DigestUpdate 和 .NET 的 TransformBlock 都明确支持增量计算，但很多人仍习惯性调 EVP_DigestFinal_ex 前把整个文件 load 进 std::vector。后果很直接：
- 4GB 文件在 32 位环境或容器中可能直接触发
std::bad_alloc - 64 位下虽不崩溃，但占用数百 MB 内存毫无必要，还会干扰其他 IO 调度
-
std::ifstream::seekg(0, std::ios::end)+tellg()对管道、设备文件失败，且 Windows text 模式下不可靠 - 用
file_size()判断大小后仍需依赖gcount()——文件可能被截断，file_size()返回的是 stat 时刻的值
怎么正确初始化和清理 OpenSSL 的哈希上下文
EVP_MD_CTX 是有状态对象，必须配对使用 EVP_MD_CTX_new 和 EVP_MD_CTX_free，漏掉任意一个分支都会泄漏或 segfault。
- 必须用
EVP_DigestInit_ex(ctx, EVP_sha256(), nullptr)初始化，第三个参数为nullptr表示默认 engine；传错（比如传NULL）可能触发未定义行为 - OpenSSL 1.1.1+ 强制要求
EVP_MD_CTX_new，旧版本用EVP_MD_CTX_create，混用必崩 - 所有提前 return 路径（如
!file.is_open()、EVP_DigestUpdate失败）都得确保调了EVP_MD_CTX_free(ctx) -
EVP_sha256()返回 const 指针，别free它
缓冲区大小和读取逻辑的关键细节
缓冲区不是越大越好，也不是越小越安全。真实瓶颈常在系统调用开销与内存驻留之间。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 推荐 64KB–1MB 区间（如
std::vector<uint8_t> buf(65536)</uint8_t>），太小（1KB）导致频繁read()系统调用，吞吐骤降 -
std::ifstream必须用std::ios::binary模式打开，否则 Windows 下\r\n会被转换，哈希值彻底错误 - 循环条件不能只靠
!file.eof()——它只在读失败后置位，末尾不满块时会多算一次 - 每次
read()后必须检查file.gcount()，它返回本次实际读取字节数；末块往往小于buf.size() - 最后一块处理要单独判断：
if (file.gcount() > 0) { EVP_DigestUpdate(...); }
输出哈希值时最容易翻车的三件事
32 字节二进制结果直接当字符串打印，99% 会出错：要么截断（遇到 \0），要么乱码，要么长度不对。
- 必须转成小写十六进制字符串（64 字符），不是 base64，不是大写，不是
printf("%x") - 每字节必须补前导零：
std::setw(2) ，否则 <code>0x05变成"5"，长度只剩 63 - 别手写 for 循环拼接——容易越界、漏字节、大小端混淆；
std::ostringstream+ 流操作符最稳 - 输出用
std::string，别返回const char*，避免悬垂指针
真正难的不是写对第一版，而是覆盖所有边界：空文件、权限不足、磁盘突然拔出、文件被其他进程截断……这些情况下的 gcount()、eof()、fail() 组合行为，比算法本身更需要实测验证。
