OpenSSL的EVP_Digest接口是计算MD5的标准方法，需用EVP_MD_CTX_new()初始化上下文，分块读取文件并调用EVP_DigestUpdate()累加，最后用EVP_DigestFinal_ex()获取16字节结果，再转为32位十六进制字符串；文件须以二进制模式打开，注意跨平台I/O差异与转换安全。
用OpenSSL库的EVP_Digest接口计算MD5
直接调MD5()函数只能处理内存数据，文件得自己读、分块喂给哈希上下文。OpenSSL的EVP_Digest系列是标准做法，兼容性好，支持大文件流式计算。
关键点：必须用EVP_MD_CTX_new()初始化上下文，不能用栈上分配；每次读BUFSIZ（比如8192字节）进缓冲区，调EVP_DigestUpdate()累加；最后EVP_DigestFinal_ex()输出16字节二进制结果。
- 别用
MD5_Init()/MD5_Update()——那是老接口，已弃用且不支持多线程安全 - 文件打开必须用
std::ios::binary模式，否则Windows下换行符会被转换，校验和错 - 读完文件后要检查
std::ifstream::gcount()是否等于请求字节数，避免EOF提前终止导致末尾数据丢失
把16字节MD5转成32字符十六进制字符串
OpenSSL输出的是原始unsigned char[16]，不是可读字符串。手动转十六进制时，每个字节要拆成高4位、低4位，映射到"0123456789abcdef"。
常见错误：用printf("%02x", byte)在C++里容易因类型提升出问题（比如char是signed，负值会补FF）；更稳妥是强制转unsigned int再格式化。
立即学习“C++免费学习笔记（深入）”；
- 别用
std::hex配合std::stringstream逐字节写——性能差，且对char类型处理不一致 - 别直接
reinterpret_cast整个16字节数组为uint32_t*再打印——大小端不一致，结果不可移植 - 推荐用查表法或
sprintf(buf, "%02x%02x...", a[0], a[1], ...)，明确控制每字节两位十六进制
跨平台读取失败或校验和不一致的排查点
同一文件在Linux和Windows上算出不同MD5，大概率不是算法问题，而是I/O层干扰。
最常踩的坑是文件路径含中文或空格时，C++ std::ifstream构造函数未正确转义；或者用fopen()时没传"rb"模式，在Windows下文本模式会把\r\n转成单个\n，导致输入数据变短。
- Linux下注意SELinux或文件权限限制——
open()返回-1但errno可能是EACCES而非ENOENT - macOS上APFS对硬链接文件可能返回不同inode，但内容相同——MD5应一致，若不一致说明某次读取被中断或缓存污染
- 调试时先用
md5sum或certutil -hashfile验证文件本身MD5，排除源文件问题
不用OpenSSL时的替代方案：Linux用md5sum命令行，Windows用CryptStringToBinary
如果项目不允许链接OpenSSL，又不想手写MD5轮子，可以走系统级调用。但要注意安全与可靠性边界。
Linux下用std::system("md5sum " + filename)简单，但有注入风险——文件名含$、`、空格时会崩；Windows下CryptStringToBinary只支持Base64解码，得先让certutil输出Base64格式再解析，链路太长。
- 绝对不要拼接用户输入到
std::system()里——哪怕加了引号也防不住shell元字符 -
certutil -hashfile file MD5输出带冒号和空格，需用substr()跳过前导文字，再删空格，再转小写 - 这些方案本质是绕过计算逻辑，适合工具脚本，不适合嵌入式或高频调用场景——启动进程开销太大
真正稳定的做法还是静态链接OpenSSL或用mbed TLS这类轻量库，自己控住输入流和内存生命周期。MD5虽已不推荐用于安全场景，但做完整性校验仍广泛存在，关键是别让I/O毁了哈希结果。
