应使用OpenSSL的EVP_MD_CTX流式分块计算文件SHA256：调用EVP_MD_CTX_new()初始化，EVP_DigestInit_ex()配置算法，循环读取64KB二进制块并用EVP_DigestUpdate()更新，最后EVP_DigestFinal_ex()获取摘要转32字节十六进制字符串，全程严格配对资源生命周期与gcount()边界判断。
直接用 OpenSSL 的 EVP_DigestUpdate 分块计算，比手写纯 C++ SHA256 实现快 3–4 倍，且更安全、更少出错——除非你明确需要无依赖、可审计或嵌入式部署，否则别自己重实现压缩函数。
为什么不用手写 SHA256 压缩逻辑
自己实现 64 轮位运算 + 消息扩展 + σ/Σ 函数，看似可控，实则极易翻车：
- 常量
K表若用浮点数截断生成，小误差会放大成最终哈希不一致 -
ROTRIGHT和SIG宏在不同字节序平台（ARM vs x86）下未显式处理对齐或符号扩展，结果可能错 - 填充逻辑漏掉大端序长度字段的高位补零，
sha256sum校验必败 - 没有 SIMD 加速时，纯标量实现吞吐常低于 100 MB/s；而 OpenSSL 启用 AVX2 后轻松突破 400 MB/s
EVP_MD_CTX 分块初始化与清理的硬性要求
OpenSSL 1.1.1+ 不允许裸指针操作，必须严格配对生命周期：
- 初始化必须用
EVP_MD_CTX_new()，不是new EVP_MD_CTX或旧版EVP_MD_CTX_create() - 每次
EVP_DigestInit_ex(ctx, EVP_sha256(), nullptr)第三个参数必须是nullptr，传NULL在某些编译器下触发未定义行为 - 所有异常路径（文件打开失败、
EVP_DigestUpdate返回 0、读取中断）都得调EVP_MD_CTX_free(ctx)，否则内存泄漏或后续segfault - 不能复用未
EVP_DigestInit_ex重置的 ctx —— 即使只算一个文件，也建议每次新建 + free，避免状态残留
分块大小与 gcount() 边界判断的关键细节
选 64KB（65536）不是玄学，是系统调用开销和缓存局部性的平衡点：
立即学习“C++免费学习笔记（深入）”；
- 缓冲区声明为
std::vector<uint8_t> buf(65536)</uint8_t>，避免栈溢出；用&buf[0]传给EVP_DigestUpdate - 必须用
std::ios::binary打开文件，Windows 下 text 模式会把\r\n转成\n，哈希值必然错 - 循环不能写
while (!file.eof())——eof()只在 read 失败后置位，末块读不满时会多进一次循环 - 每次
file.read(&buf[0], buf.size())后，必须检查file.gcount()：它才是本次真实读取字节数；仅当gcount() > 0才调EVP_DigestUpdate
输出 32 字节哈希到十六进制字符串的常见崩点
直接 std::cout 或 <code>printf("%s", hash_bytes) 会因内部含 \0 截断或乱码：
- 哈希结果是纯二进制
uint8_t[32]，不是 C 字符串，绝不能当char*用 - 正确做法：逐字节用
std::sprintf(hex + i*2, "%02x", hash[i])或fmt::format("{:02x}", hash[i]) - 注意大小写：
sha256sum输出小写，若用%02X得到大写，校验比对会失败 - 别忘了最后调
EVP_DigestFinal_ex(ctx, digest, &len)—— 没这步，digest里全是 0
真正难的从来不是“怎么算”，而是“怎么确保每一步都不被系统、平台、边界条件悄悄篡改”。哪怕只漏一个 gcount() 判断，校验值就和 sha256sum 对不上；哪怕只传错一个 nullptr，程序可能在某台 CentOS 机器上静默崩溃。这些点不写进代码注释里，下次维护的人还得踩一遍。
