应使用OpenSSL的EVP_DigestInit_ex、EVP_DigestUpdate、EVP_DigestFinal_ex三步流式计算SHA-256，以std::ifstream二进制模式分块读取（如8192字节），用gcount()获取实际字节数，最终将32字节摘要转为小写十六进制字符串。
如何用 C++ 计算文件的 SHA-256 散列值
直接读取整个文件再喂给哈希函数会爆内存，尤其处理 GB 级日志或固件镜像时。必须流式计算，边读边更新哈希状态。
推荐用 OpenSSL 的 EVP_DigestInit_ex + EVP_DigestUpdate + EVP_DigestFinal_ex 三步流式处理，比手写 SHA-256 轮函数安全且跨平台兼容性好。
- 打开文件用
std::ifstream并设为二进制模式：std::ios::binary - 每次读
8192字节（避免太小导致系统调用过多，太大无必要） - 调用
EVP_DigestUpdate传入缓冲区地址和实际读取字节数，不是固定 8192 - 最终结果是 32 字节 raw data，转成十六进制字符串时注意补前导零（如
0a不能变成a）
对比散列值时为何 strcmp 失败但 memcmp 成功
常见错误是把两个 hex 字符串用 strcmp 比较，却忽略了大小写 —— OpenSSL 默认输出小写，但别人给的参考值可能是大写 SHA256SUM 文件，或 Python 的 hashlib.sha256().hexdigest().upper()。
更稳妥的做法是：先统一转小写再 strcmp，或直接用 memcmp 比原始 32 字节摘要（跳过字符串转换环节）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 若已得两个 hex 字符串
str1和str2，用std::equal(str1.begin(), str1.end(), str2.begin(), [](char a, char b) { return std::tolower(a) == std::tolower(b); }) - 若持有两个
unsigned char[32]，直接memcmp(digest1, digest2, 32) == 0 - 不要用
std::string::operator==对未标准化大小写的 hex 字符串做比较
为什么校验失败不等于“一定被篡改”
散列校验只是检测内容是否变化，不说明变化原因。很多看似“非法篡改”的情况其实是合法行为导致的：
- 文本文件换行符差异：Windows 写入
\r\n，Linux 下校验时用 LF-only 打开，内容实际不同 - 文件末尾自动添加换行：某些编辑器（如 Vim 的
fixeol）保存时会补\n - 时间戳/元数据变更不影响内容，但若校验的是整个文件（含扩展属性），
stat或xattr变化也会让散列不匹配 - 磁盘静默损坏（silent corruption）也可能导致散列不一致，此时不是“被篡改”，而是存储故障
生产环境校验需绕开的陷阱
真实部署中，最容易被忽略的是文件权限、符号链接和空文件处理。
- 用
std::filesystem::is_symlink()显式检查路径是否为软链，否则可能误校验目标文件而非链接本身（取决于需求） - 空文件的 SHA-256 是确定值（
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855），但若读取时read()返回 0 且没检查eof()和fail()，可能跳过计算 - 权限不足时
ifstream构造可能不报异常（默认不开启exceptions()），需手动检查ifile.good() == false - 不要在计算中途捕获
std::exception就完事 —— OpenSSL 错误需查ERR_get_error()，否则可能掩盖初始化失败
散列校验逻辑本身很稳定，真正出问题的永远是文件访问路径、编码解释、边界条件这三块。
