不能直接用std::thread对整个文件做多线程读取，因为磁盘I/O是瓶颈，多线程争抢seek/read引发锁竞争和缓存失效，且MD5是串行算法，分片哈希后无法正确合并，必须保证字节顺序严格一致地流式更新。
为什么不能直接用 std::thread 对整个文件做多线程读取？
因为磁盘 I/O 是瓶颈，多个线程争抢同一块文件的 seek 和 read 会引发大量锁竞争和缓存失效，实际速度可能比单线程还慢。更关键的是，MD5 是串行算法——中间状态必须按字节顺序累积，不能简单把文件切片后各自哈希再拼接。
- 错误做法：
thread1 → hash(file[0..1MB])，thread2 → hash(file[1MB..2MB])，然后试图合并两个MD5值 → 结果必然错误 - 正确思路：只并行「读取 + 预处理」，核心哈希仍需串行「流式更新」，但可通过内存预取、零拷贝传递、无锁队列等方式隐藏 I/O 延迟
- 典型场景：处理 >1GB 的日志、镜像或数据库 dump 文件，且 CPU 核心数 ≥4
用 mmap + std::async 分块预加载，避免阻塞主线程
Linux/macOS 下用 mmap 将大文件映射为内存区域，配合 std::async(std::launch::async, ...) 启动后台任务提前将下一块数据加载进页缓存（page cache），让后续 MD5_Update 调用几乎不触发缺页中断。
- 关键点：分块大小建议设为 4MB～16MB（对齐
getpagesize()），太小增加调度开销，太大降低并行粒度 - 不要在
async里调用MD5_Update—— 这会破坏哈希顺序；只做madvise(..., MADV_WILLNEED)或memset(buf, 0, size)触发预读 - Windows 替代方案：用
CreateFileMapping+MapViewOfFileEx，并调用PrefetchVirtualMemory
用 OpenSSL 的 MD5_Init/MD5_Update 流式更新，别碰 MD5_Final 太早
OpenSSL 的 MD5_CTX 支持增量更新，只要保证字节顺序严格一致，就能边读边算。重点是控制好「读取缓冲区」和「哈希上下文」的生命周期，避免跨线程共享 MD5_CTX 实例（它不是线程安全的）。
- 安全模式：单线程持有唯一
MD5_CTX，其他线程只负责生产std::span<const uint8_t></const>数据块，通过std::queue或moodycamel::ConcurrentQueue传递 - 性能陷阱：频繁调用
MD5_Update(ctx, ptr, len)小于 64 字节时，OpenSSL 内部会缓存未对齐数据，导致额外 memcpy；建议批量聚合到 ≥64 字节再提交 - 别用
MD5()全量函数——它内部封装了 Init/Update/Final，无法流式接入
验证结果是否可信：对比 md5sum 输出，注意换行符和路径处理
最终生成的 32 字符十六进制字符串，必须和系统命令 md5sum /path/to/file 完全一致（不含空格、不含前缀）。常见偏差来源不是算法，而是文件打开方式或边界处理。
立即学习“C++免费学习笔记（深入）”；
- 务必用
std::ios::binary打开文件，Windows 下若用文本模式读取会把\r\n转成\n，哈希值立刻失效 - 检查是否误读了文件末尾的 EOF 标记或 BOM 头（尤其 UTF-8 文件）；可用
hexdump -C file | head -n1对照首字节 - 如果用
mmap，确认len参数精确等于stat.st_size，不要依赖strlen或find('\0')
真正难的不是并发，是确保每一块字节被读取一次、仅一次、顺序不变地喂给哈希器——其余都是围绕这个目标做延迟掩盖和资源调度。
