不能直接用 std::thread 对文件指针并发读取，因为文件流对象（如 std::ifstream）非线程安全，多线程调用 seekg()+read() 会互相覆盖文件位置，且底层 os 缓存与流缓冲区干扰实际读取；正确做法是每个线程独立打开文件并定位读取。
为什么不能直接用 std::thread 对文件指针做并发读取
因为文件描述符（或 std::ifstream）本身不是线程安全的：多个线程调用 seekg() + read() 会互相覆盖文件位置，导致块错位、重复读或跳读。哪怕你手动算好偏移量，底层 OS 缓存和 C++ 流缓冲区也会干扰实际读取行为。
- 正确做法是每个线程独立打开文件（
open()或构造新std::ifstream），用seekg(offset)定位后读固定长度 —— 文件系统支持随机读，但不保证流对象共享安全 - 注意：Windows 上用
FILE_SHARE_READ，Linux/macOS 默认允许多进程/线程只读打开同一文件，无需额外配置 - 避免用
std::fstream::tellg()在多线程中校验位置，它可能返回 -1 或未定义值；应以传入的offset和length为准
如何分块才不会破坏 MD5 的输入语义
MD5 是逐字节累积哈希，不能简单把文件切成几段、各自算 MD5 再拼接 —— 那得到的是 N 个哈希值，不是原文件的哈希。必须模拟「顺序流式输入」，即用 MD5_Update() 按原始字节序喂数据。
- 分块只是为了并行读取 I/O，哈希计算仍需串行合并：各线程读完自己的块后，把原始字节（或内存视图）发回主线程，按 offset 排序后喂给一个全局
MD5_CTX - 更高效的做法是使用支持「增量更新 + 中间状态导出」的哈希库（如 OpenSSL 的
MD5_Final()不支持中断续哈希；但你可以自己缓存中间MD5_CTX.h[0..3]状态，不过这超出标准 API，易出错） - 实战推荐方案：只并行读，不并行算 —— 用
std::async(std::launch::async, read_chunk, fd, offset, len)加速加载，所有 chunk 收齐后再单线程调用MD5_Update()，平衡 CPU 和 I/O
用 mmap 替代 read() 能提速吗？什么情况下反而更慢
在 Linux/macOS 上，mmap() 可避免内核态到用户态的数据拷贝，对大文件随机读有优势；但它不是银弹。
- 必须用
MAP_PRIVATE | MAP_POPULATE（后者预加载页，避免缺页中断阻塞线程）；否则首次访问映射区域时会卡住，失去并行意义 - 小块读（比如每块 64KB）+ 高并发线程数 > 物理核心数时，
mmap的 TLB 压力和页表开销可能超过收益，实测比pread()慢 10%~20% - Windows 上
CreateFileMapping()+MapViewOfFile()行为类似，但要注意SEC_COMMIT标志和内存配额限制，超大文件（>2GB）可能映射失败 - 简单判断：若文件能完整装进空闲物理内存，且块大小 ≥ 1MB，
mmap更稳；否则老实用pread()或fseek()+fread()
OpenSSL 的 MD5_Init()/MD5_Update() 在多线程下要加锁吗
不需要 —— 每个线程用自己独立的 MD5_CTX 实例完全没问题。但如果你试图让多个线程往同一个 MD5_CTX* 里写，就会踩内存越界或状态错乱，因为 MD5_CTX 包含 4 个 unsigned long 累加器和一个 64 字节缓冲区，无任何原子保护。
- 错误写法：
static MD5_CTX g_ctx; std::thread([&]{ MD5_Update(&g_ctx, buf, len); });→ 数据竞争，结果不可预测 - 正确写法：每个线程声明自己的
MD5_CTX ctx; MD5_Init(&ctx); MD5_Update(&ctx, buf, len);，但注意这只是算“该块的哈希”，不是最终结果 - 真正要锁的，是把各块数据按顺序提交给最终哈希器的那个环节（比如一个线程安全队列或带 mutex 的 vector），而不是哈希函数本身
pread() 读 1MB 块，比单线程快不到 3 倍——因为文件系统和驱动层的队列深度、IO 调度策略早成了新瓶颈。这时候与其堆线程，不如先确认是否真的需要 MD5：SHA-256 硬件加速在现代 CPU 上已很成熟，而 MD5 已不被推荐用于安全场景。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
