最可靠方式是用OpenSSL的EVP_DigestInit_ex、EVP_DigestUpdate、EVP_DigestFinal_ex三步流式计算SHA-256：以二进制模式分块读取文件（如8192字节），每次调用EVP_DigestUpdate更新哈希状态，最后将32字节摘要转为小写十六进制字符串。
用OpenSSL的EVP接口计算SHA256最可靠
直接调用OpenSSL的EVP_DigestInit_ex、EVP_DigestUpdate和EVP_DigestFinal_ex是C++里最通用、跨平台且经生产验证的方式。别用自己手搓哈希逻辑，也别依赖系统命令（如sha256sum），它们要么不可控，要么不跨平台。
常见错误是把整个文件一次性读进内存再喂给哈希函数——遇到GB级文件就OOM。正确做法是分块读取、增量更新：
- 每次用
fread读取固定大小缓冲区（如8192字节） - 每读一块就调用一次
EVP_DigestUpdate - 确保
feof或ferror判断读取结束，避免最后一次短读被忽略 - 最后调用
EVP_DigestFinal_ex获取32字节结果，再转成十六进制字符串
Windows下用CryptoAPI会踩坑
Win32的BCryptHashData虽能算SHA256，但默认只支持BCRYPT_SHA256_ALGORITHM在Windows 8+，XP/7需回退到CryptAcquireContext + CryptCreateHash，而后者对SHA256支持不稳定——部分旧版CryptoAPI根本不识别CALG_SHA_256，会静默失败或返回ERROR_INVALID_PARAMETER。
除非你明确限定运行环境为Win10+且不允许链接OpenSSL，否则不建议走这条路。更麻烦的是：CryptoAPI的哈希对象必须显式CryptDestroyHash，漏掉就会句柄泄漏。
立即学习“C++免费学习笔记（深入）”；
std::filesystem + OpenSSL组合读文件最安全
用std::ifstream以std::ios::binary打开文件没问题，但要注意：ifstream::seekg在大文件上可能受off_t位宽限制（32位系统上限2GB）；std::filesystem::file_size能提前确认大小，但本身不保证原子性——文件可能被其他进程截断。
实操建议：
- 优先用
std::FILE*配fopen(..., "rb")，它对大文件兼容性更好 - 打开后立即用
fseek(fp, 0, SEEK_END)+ftell校验是否可定位（某些网络文件系统不支持） - 若
ftell返回-1，说明无法预知长度，只能边读边哈希，跳过预分配步骤 - 缓冲区大小选4096或8192，太小增加系统调用开销，太大无益（CPU缓存友好性已饱和）
输出32字节二进制结果还是64字符十六进制？
校验场景下必须输出十六进制字符串——这是SHA256的标准文本表示，方便人工比对、日志记录或HTTP头传输。直接返回unsigned char[32]容易误当成C字符串处理，导致截断（遇到\0就停）。
转换时注意：
- 用
sprintf(buf, "%02x", digest[i])逐字节格式化，%02x确保补零（如0x7 → "07"） - 别用
std::hex 流操作，它在多线程下有状态污染风险 - 最终字符串长度严格为64，少一位说明某字节转换出错（比如用了
%x没补零） - 生成的字符串全部小写，和
sha256sum工具输出一致，避免大小写混淆
真正难的不是调API，而是处理边界：空文件、权限拒绝、设备文件（如/dev/random）、NFS挂载点中断。这些情况不会让哈希函数报错，但会让fread返回0或-1——必须检查每次读取的返回值，而不是只看EOF。
