直接用hashlib.md5(file.read())会崩内存，因为file.read()将整个GB级文件一次性加载进内存，触发MemoryError；正确做法是rb模式分块读取（如8192字节），循环update()增量计算MD5。
为什么直接用 hashlib.md5(file.read()) 会崩内存？
读取几个 GB 的文件时，file.read() 会把整个内容加载进内存，极易触发 MemoryError 或拖慢系统。MD5 不需要一次性全量数据，它支持增量更新——这是解决大文件哈希的核心前提。
正确做法：分块读取 + update() 增量计算
用固定缓冲区（如 8192 字节）循环读取，每次调用 md5.update() 累积哈希状态。既不爆内存，又保持标准 MD5 算法一致性。
实操建议：
- 缓冲区大小选
8192或65536（64KB），太小增加系统调用开销，太大无实质收益 - 务必以二进制模式打开文件：
open(path, "rb")，文本模式会破坏字节流 - 不要用
readline()，它按行切分，会破坏块边界和哈希结果
import hashlib
def get_md5(filepath):
md5 = hashlib.md5()
with open(filepath, "rb") as f:
for chunk in iter(lambda: f.read(8192), b""):
md5.update(chunk)
return md5.hexdigest()
遇到 OSError: [Errno 24] Too many open files 怎么办？
不是哈希逻辑的问题，而是你并发调用了太多 get_md5()，且没及时释放文件句柄。Python 的 with open 虽能自动 close，但若在循环里快速创建大量文件对象，仍可能超限。
立即学习“Python免费学习笔记（深入）”；
排查与缓解：
- 检查是否在多线程/多进程里密集调用，确认每个
with块都完整执行完毕 - Linux 下可用
ulimit -n查当前限制，临时调高用ulimit -n 65536 - 更稳妥的做法是加异常兜底：
try/finally中显式f.close()（尽管with已覆盖多数场景）
对比 subprocess 调用系统 md5sum 是否更快？
在 Linux/macOS 上，原生命令通常略快（C 实现 + 零 Python 解释开销），但差异一般不超过 10%；Windows 的 certutil 则慢不少。真正影响体验的是可移植性和错误处理。
权衡点：
- 用系统命令需自行解析 stdout、处理路径空格、兼容不同平台命令名（
md5sum/md5/certutil） - Python 原生方案逻辑可控，调试方便，且能自然集成到异常流或进度回调中
- 如果只是偶尔校验，命令行够用；如果是嵌入工具链或服务中，坚持纯 Python 更稳
真正容易被忽略的是：某些 NAS 或只读挂载点下，os.stat() 可能卡住，而哈希过程本身不感知——别在哈希前盲目加文件存在性检查，除非你明确需要它。
