必须以二进制模式打开文件，用std::ifstream逐块读取（如4KB），喂给zlib的crc32()或OpenSSL的EVP_MD_CTX流式计算，避免文本模式换行转换、一次性加载内存溢出及seekg/tellg平台差异导致的校验失败。
怎么用C++计算文件的CRC32或MD5值
直接读文件二进制内容，喂给标准哈希算法实现即可。别用文本模式打开——fopen("file.txt", "r")会丢字节、换行符被转义，校验必然失败；必须用"rb"模式。
推荐做法：用std::ifstream以std::ios::binary打开，逐块读取（比如4KB/次），喂给CRC32或MD5更新函数。避免一次性加载大文件到内存，也防止seekg(0, std::ios::end)后tellg()在某些平台返回-1的坑。
- CRC32可用
zlib的crc32()函数，头文件<zlib.h>，初始值传Z_CRC32_INIT - MD5推荐
openssl/evp.h里的EVP接口，比直接用md5.h更稳定；初始化用EVP_MD_CTX_new()，算法选EVP_md5() - 别手写MD5——轮函数、常量、位运算极易出错，且无编译器优化
为什么校验值对不上？常见掉坑场景
校验失败不等于被篡改，大概率是环境不一致导致的“假阳性”。最常踩的三个坑：
- Windows下用
"w"写入文本，再用"rb"读取——CR/LF自动转义没发生，但原始文件里可能已有\r\n，而你生成校验时用的是Unix风格换行 - 文件末尾有BOM（如UTF-8 BOM
0xEF 0xBB 0xBF），编辑器保存时悄悄加了，但你本地生成校验用的是无BOM版本 - 路径含中文或空格，
std::ifstream构造失败却没检查is_open()，后续read()返回0字节，CRC算出来恒为0或0xFFFFFFFF
调试时先打印实际读取字节数：ifs.gcount()，确认和std::filesystem::file_size()一致。
立即学习“C++免费学习笔记（深入）”；
如何安全比对两个校验值
别用std::string存MD5——容易被截断或编码混淆；CRC32用uint32_t，MD5用std::array<uint8_t></uint8_t>（原始二进制）或std::string十六进制小写字符串（如"d41d8cd98f00b204e9800998ecf8427e"）。
- 比对原始二进制时，用
std::memcmp()，不是==（std::array支持，但uint8_t*不行） - 比对十六进制字符串时，确保两端都是小写、无空格、长度32——
openssl默认输出小写，但某些工具（如certutil -hashfile）输出大写 - 别用
std::string::compare()前忘了std::transform(s.begin(), s.end(), s.begin(), ::tolower)
生产环境要注意的边界点
大文件（>2GB）、网络文件系统（NFS）、只读挂载点、符号链接，都会让常规file_size()或read()行为异常。
-
std::filesystem::file_size()在某些旧libc上对大于2GB文件返回static_cast<uintmax_t>(-1)</uintmax_t>，需配合stat64验证 - 读取过程中
ifs.gcount() < bufsize不一定是EOF——可能是磁盘I/O错误，检查ifs.good()和ifs.eof()组合判断 - 符号链接默认被
std::ifstream跟随，若需校验链接自身（而非目标），得用std::filesystem::read_symlink()并手动处理
真正关键的不是算法多快，而是读取过程是否零误差还原了物理字节流——哪怕一个字节偏差，CRC32就全崩，MD5雪崩效应更彻底。
