不能用 std::hash 或手写 CRC32/MD5，因其跨平台不一致、参数不标准、文本模式读取导致字节错位；应使用 zlib crc32() 或 OpenSSL EVP_MD_CTX，并以二进制模式分块读取且校验 gcount()。
为什么不能用 std::hash 或自己手写 CRC32/MD5
std::hash 不是为文件校验设计的：它不保证跨平台、跨编译器结果一致，同一文件在 GCC 和 MSVC 下输出可能完全不同；更严重的是，它不处理字节序、填充规则、初始向量等密码学哈希必需要素。手写 MD5 更危险——RFC 1321 规定的 64 字节块补位（0x80 + 若干 0x00 + 64 位长度）、轮函数常量、大端存储顺序，漏掉任一环节就和 md5sum 对不上。CRC32 同理，仅多项式（0xEDB88320 vs 0x04C11DB7）、初始值（0 vs 0xFFFFFFFFU）、终值异或（是否 ^ 0xFFFFFFFFU）这三项参数组合就有至少 8 种常见变体，cksum、zlib、Python zlib.crc32、Windows CertUtil 全都不一样。
必须用二进制模式分块读取，且检查 gcount()
文本模式打开文件（如 std::ifstream f(path) 默认行为）在 Windows 下会把 \r\n 自动转成单个 \n，导致实际喂给哈希函数的字节数变少、内容错位，校验必然失败。正确做法是显式指定 std::ios::binary，并用 read() + gcount() 获取真实读取长度：
-
f.read(buf.data(), buf.size())后必须检查f.gcount()—— 它可能小于buf.size()（如文件末尾不足一块），不能直接拿buf.size()当 len 传给crc32()或EVP_DigestUpdate() - 避免
seekg(0, std::ios::end); tellg()获取长度：某些 FAT32 或网络文件系统返回-1，后续vector分配失败 - 别用
rdbuf()转 string：locale 会影响换行符处理，且 string 可能截断\0
推荐库与参数组合：zlib crc32() 和 OpenSSL EVP_MD_CTX
轻量且可靠的选择：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- CRC32：用 zlib 的
crc32()，头文件<zlib.h>，调用时初始值传0xFFFFFFFFU，返回值再^ 0xFFFFFFFFU，即crc32(0xFFFFFFFFU, buf, len) ^ 0xFFFFFFFFU，与cksum -o3和 Pythonzlib.crc32(data) & 0xffffffff对齐 - MD5/SHA-256：用 OpenSSL 的
EVP_MD_CTX流式接口，初始化用EVP_MD_CTX_new()+EVP_DigestInit_ex(ctx, EVP_md5(), nullptr)（MD5）或EVP_sha256()（SHA-256），循环EVP_DigestUpdate()，最后EVP_DigestFinal_ex()输出原始字节；不要用已废弃的md5.h单头文件实现 - 输出比对：MD5 存为 32 字符小写十六进制字符串（如
"d41d8cd98f00b204e9800998ecf8427e"），SHA-256 存为 64 字符小写十六进制；比对用std::equal或直接==（字符串已标准化）
校验失败 ≠ 被篡改，先排查三个隐形坑
90% 的“校验失败”其实不是内容被改，而是环境不一致：
立即学习“C++免费学习笔记（深入）”；
- 文件带 UTF-8 BOM（
0xEF 0xBB 0xBF）：编辑器悄悄加了，但你生成参考哈希时用的是无 BOM 版本 - 换行符混用：
\r\n（Windows）vs\n（Linux/macOS），尤其文本配置文件跨平台传输后 - 路径含中文或空格导致
std::ifstream构造失败却没检查is_open()，后续read()返回 0 字节，CRC 恒为0或0xFFFFFFFF
调试时第一件事：打印 std::filesystem::file_size(path) 和 f.gcount()，两者必须相等；再用 xxd -p file.bin | tr -d '\n' 和程序输出的十六进制原始字节逐位对比，绕过所有字符串格式化干扰。
