默认hashlib.md5()处理大文件慢的主因是io读取方式不当，而非算法本身；优化需控制块大小（sata用64kb、nvme用1–4mb）、避免内存拷贝、合理并发（预分片+mmap+memoryview），并注意openssl直调的适用条件与资源泄漏风险。
为什么默认的 hashlib.md5() 处理大文件会慢
不是算法本身慢，而是读取方式拖了后腿。比如用 f.read() 一次性加载 2GB 文件，内存直接爆掉；用 f.readlines() 会把换行符当分界，二进制文件里根本没换行，结果卡死或报错；f.readline() 在纯二进制大文件里也几乎无效——它会一直找 \n，直到 EOF，实际变成单次读完整个文件。
真正瓶颈在：IO 等待 + 内存拷贝 + 哈希更新粒度太粗。优化核心就三条：控制每次读多少、避免额外复制、让 CPU 别闲着。
f.read() 的块大小怎么设才不坑人
4KB（4096）是很多教程写的“安全值”，但实测对 SSD 或 NVMe 磁盘来说太小——线程调度和系统调用开销占比太高；设成 128MB 又容易触发 swap 或阻塞其他 IO。
- 普通 SATA 机械盘：用
65536（64KB）较稳 - NVMe/高速 SSD：推荐
1048576（1MB）到4194304（4MB） - 注意 Windows 下某些 AV 软件会劫持小块读取，导致延迟毛刺，可临时关掉实时防护测试
- 别用
iter(lambda: f.read(n), b'')套路——它在 Python 3.12+ 有已知 GC 开销，老老实实用while chunk := f.read(n):
多线程并行算 MD5 为什么反而更慢
因为没隔离好资源竞争。多个线程共用一个 file object，f.seek() 和 f.read() 会互相覆盖位置；或者全用 open() 打开同一文件，底层 fd 冲突，Linux 返回 EBUSY，Windows 直接抛 PermissionError。
正确做法是每个线程处理独立文件，或对单文件做**预分片 + mmap + memoryview**：
- 先用
os.stat(file_path).st_size获取总长度 - 按 4MB 切出偏移区间：
[(0, 4194304), (4194304, 8388608), ...] - 每个线程用
mmap.mmap(f.fileno(), length, offset=...)映射对应段 - 传入
memoryview(mmap_obj)给hashlib.md5().update()，零拷贝 - 最后按原始顺序拼接各段哈希再整体 hash（不是简单拼字符串！要用
MD5_Update连续喂）
OpenSSL C 接口真比 hashlib 快吗
快，但只在特定条件下：文件 >500MB、CPU 核数 ≥8、OpenSSL 版本 ≥1.1.1。Python 的 hashlib 底层其实也调 OpenSSL，但加了一层 PyObject 封装，对小块数据影响不大，大块时差异明显。
绕过封装直接调用，关键点有三个：
- Linux/macOS 加载
libcrypto.so.1.1或libcrypto.dylib，Windows 必须用libcrypto-1_1-x64.dll（32 位 Python 需 32 位 DLL） - 不能直接传
memoryview给 C 函数，得用ctypes.create_string_buffer()或bytearray转换 - 务必检查
MD5_Init/MD5_Update/MD5_Final返回值，OpenSSL 错误不抛异常，只返回 0
最易被忽略的是：mmap 映射后忘了 mmap_obj.close()，会导致文件句柄泄漏，跑批量任务几小时后直接 OSError: Too many open files。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
