必须立刻读file.gcount()，因read()返回流对象而非字节数；末块不满时gcount()才是唯一可信的实际读取量，漏则导致哈希错、解析崩、越界访问。
大文件不能一次性读进内存，否则大概率触发 std::bad_alloc 或拖垮系统响应；必须用分块流式读取 + 增量状态更新，核心是控制内存驻留、对齐真实字节数、严守上下文生命周期。
为什么 std::ifstream::read(buf, size) 后必须立刻读 file.gcount()
因为 file.read() 的返回值是流对象本身（用于链式调用），**不反映实际读了多少字节**。末块不满缓冲区时，file.gcount() 才是唯一可信值——它返回本次 read() 真实写入缓冲区的字节数。漏掉这步，会导致 EVP_DigestUpdate() 或 XML/SAX 解析器喂入错误长度，哈希错、解析崩、越界访问全都有可能。
- 别用
!file.eof()控制循环：它只在读失败后置位，最后一次空读仍会进循环一次 - 别依赖
file.fail()判断结束：它可能因格式错误（如 XML 乱码）而设位，但文件还没读完 - 正确循环条件示例：
while (file.read(buf.data(), buf.size()) || file.gcount() > 0)
缓冲区大小选 8192 还是 65536？看 I/O 路径
太小（如 512）会让 read() 系统调用频次飙升，CPU 花在上下文切换上；太大（如 1048576）则浪费内存驻留，还可能挤占页缓存影响其他 IO。实测在本地 SSD 上，65536（64KB）和 8192（8KB）吞吐差异不到 3%，但前者在 NFS 或容器挂载场景下易因内核页缓存压力升高而变慢。
- 本地磁盘（ext4/xfs + NVMe/SSD）：优先用
std::vector<uint8_t> buf(65536)</uint8_t> - 网络存储、容器挂载、不确定环境：回落到
8192，更保守 - 绝对别用
std::vector<char>(file_size)</char>预分配——这是典型反模式，file_size()在管道、设备文件上直接失败，且无法反映实时截断/追加
EVP_MD_CTX 必须严格配对 EVP_MD_CTX_new() 和 EVP_MD_CTX_free()
EVP_MD_CTX 不是 POD 类型，也不是线程安全的可复用对象。OpenSSL 1.1.1+ 强制要求用工厂函数管理生命周期，漏掉任意一个 free 都会泄漏 OpenSSL 内部堆内存；提前 return 时没 free 更会导致后续调用 segfault。初始化必须用 EVP_DigestInit_ex(ctx, md, nullptr)，第三个参数传 nullptr（不是 C 风格 NULL），否则某些平台行为未定义。
- 所有出错路径（
!file.is_open()、EVP_DigestInit_ex()失败、EVP_DigestUpdate()返回非 1）都必须调EVP_MD_CTX_free(ctx) - 建议用 RAII 封装或
goto cleanup，避免遗漏 - 多线程环境下每个线程必须独占一个
ctx，不能共享未重置的上下文
二进制模式打开文件是硬性前提
Windows text 模式下会把 \r\n 自动转成单个 \n，导致哈希值彻底错乱、XML 解析器在换行处失同步、JSON SAX 回调拿到的字符串长度与实际不符。无论算 MD5、SHA256，还是用 rapidjson::Reader 或 xmlSAXHandler，都必须显式指定 std::ios::binary。
- 错误写法：
std::ifstream file("data.bin")（默认 text 模式） - 正确写法：
std::ifstream file("data.bin", std::ios::binary) - 用
fopen()时也一样：fopen("data.bin", "rb")，"r"不够
真正容易被忽略的是：流式处理不是“分块读”就完了，而是每一块的边界、每一个回调的触发时机、每一次上下文清理，都必须和算法本身的字节序、填充规则、状态迁移对齐。少一个 gcount()、多一次 eof() 判断、漏一次 free()，结果就不可信。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
