必须用OpenSSL等第三方库分块流式计算文件哈希，因std::hash不支持密码学哈希且无法处理大文件；需以binary模式读取、用gcount()校验每块实际字节数、严格配对EVP_MD_CTX初始化与释放，并将32字节摘要转为小写十六进制字符串。
用 std::hash 或第三方库计算文件哈希值
标准 C++20 之前没有内置的通用哈希函数支持大文件二进制读取和分块计算，std::hash 只适用于小对象（如 std::string、int），不能直接用于文件。实际项目中必须自己读取文件并喂给哈希算法。
推荐用 OpenSSL（SHA256）、libsodium（crypto_hash_sha256）或纯头文件库如 xxHash。若受限于环境无法引入外部依赖，可手写 SHA-256 实现（但不建议——易出错且难审计）。
- 优先选
OpenSSL：成熟、支持流式计算、有完整错误检查 - 避免用
MD5：已不安全，仅用于兼容旧系统校验 - 读取时用
std::ifstream以std::ios::binary模式打开，否则 Windows 下换行符会被转换，导致哈希不一致
分块读取大文件避免内存溢出
上传文件可能达 GB 级，一次性 read 到内存会触发 OOM。必须分块（chunk）读取并增量更新哈希上下文。
以 OpenSSL 为例：EVP_DigestUpdate 支持多次调用，每次传入一块数据；最终调用 EVP_DigestFinal_ex 获取摘要。块大小建议设为 8KB–64KB（4096 或 65536），太小增加系统调用开销，太大无实质收益。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
unsigned char hash[SHA256_DIGEST_LENGTH];
EVP_MD_CTX* ctx = EVP_MD_CTX_new();
EVP_DigestInit_ex(ctx, EVP_sha256(), nullptr);
std::ifstream file("upload.bin", std::ios::binary);
char buf[65536];
while (file.read(buf, sizeof(buf)) || file.gcount() > 0) {
EVP_DigestUpdate(ctx, buf, file.gcount());
}
EVP_DigestFinal_ex(ctx, hash, nullptr);
EVP_MD_CTX_free(ctx);
比对哈希值时注意编码与大小写
服务端生成的哈希值通常是十六进制字符串（如 "a1b2c3..."），但客户端可能传 base64 编码（如 "oTIz..."）或全大写/小写格式。直接字符串比较会失败。
- 统一转为小写十六进制再比对（
std::tolower遍历每个字符） - 若客户端传的是
base64，服务端需先用EVP_DecodeBlock或简易 base64 解码，再与原始摘要字节数组比对 - 避免用
std::string::compare直接比对不同编码结果——这是最常见的校验失败原因
HTTP 上传场景下校验时机与风险点
不能在文件完全写入磁盘后再计算哈希——这会放大失败成本（上传完成才发现损坏）。理想做法是边接收边计算。
例如用 libcurl 的 WRITEFUNCTION 回调，或 HTTP 框架（如 cpp-httplib）的 on_request 中逐块处理 body 数据，并同步喂给哈希上下文。这样即使网络中断，也能及时丢弃无效上传。
- 注意 multipart boundary 解析：不要把 boundary 字符串误计入哈希
- 若用临时文件中转，确保
fsync或flush完成后再开始哈希计算，否则可能读到缓存脏数据 - 并发上传时，每个请求必须独占自己的哈希上下文（
EVP_MD_CTX*），共享会导致状态混乱
哈希本身不防恶意篡改，只验证完整性；如果需要抗攻击，得配合签名或 TLS 传输层保护。另外，SHA-256 输出是 32 字节二进制，转 hex 是 64 字符，别和 SHA-1（40 字符）搞混——长度不对基本就是算法用错了。
