64 MB 数据，各种哈希算法的吞吐：

算法                      吞吐      相对 SHA-256            用途
---------------------------------------------------------------------
xxHash3-64          7499 MB/s         18.80x       哈希表 / 去重
xxHash64            6119 MB/s         15.34x       哈希表 / 去重
CRC32 (zlib)        2966 MB/s          7.44x       校验传输错误
Adler32             2561 MB/s          6.42x       校验传输错误
SHA-1                853 MB/s          2.14x       已破, 勿用
MD5                  619 MB/s          1.55x       已破, 勿用
SHA-512              562 MB/s          1.41x       签名 / 指纹
BLAKE2b              532 MB/s          1.33x       签名 / 指纹
SHA-256              399 MB/s          1.00x       签名 / 指纹
SHA3-256             316 MB/s          0.79x       签名 / 指纹

先看最尴尬的一行对比：

SHA-1   853 MB/s
MD5     619 MB/s      ← 慢 38%

MD5 既不安全，也不快。

很多人选 MD5 的理由是「它快，我又不需要安全」。但在今天的 CPU 上，MD5 比同样已被攻破的 SHA-1 慢了 38%，比安全的 BLAKE2b 慢 ——

等等，BLAKE2b 是 532 MB/s，MD5 是 619 MB/s，MD5 确实还快一点。但差距只有 16%，而 BLAKE2b 是密码学安全的。

MD5 慢的原因是它的结构天生串行——每一步都依赖上一步的结果，没法用 SIMD 并行化。而 SHA-1 的消息扩展部分有足够的指令级并行度，OpenSSL 用 AVX2 做了深度优化。

「MD5 快」是 2005 年的常识，今天它只剩下「不安全」这一个属性。

如果你需要的是「快」

xxHash3 的 7499 MB/s，是 SHA-256 的 18.8 倍。

它不是密码学哈希——给定一个输出，构造碰撞是平凡的。但如果你的用途是：

• 哈希表的 key 分布
• 数据去重 / 内容寻址
• 分片路由
• 缓存键

这些场景不存在「攻击者故意构造碰撞」的威胁模型（或者说，威胁来自别处），那用加密哈希就是纯粹的浪费——你花了 19 倍的 CPU 买了一个你不需要的性质。

如果你需要的是「安全」

别用 SHA-256，试试 BLAKE2b。

BLAKE2b    532 MB/s     1.33x
SHA-256    399 MB/s     1.00x

快 33%，安全性不低于 SHA-3（它是 SHA-3 竞赛决赛算法 BLAKE 的改进版），而且 Python、Go、Rust 的标准库都内置。

顺带解释一下 SHA3-256 为什么最慢（316 MB/s）：Keccak 的设计目标是硬件友好和抗侧信道，不是软件吞吐。 它赢得 SHA-3 竞赛靠的是结构上和 SHA-2 完全不同（海绵结构 vs Merkle-Damgård），这样万一 SHA-2 被攻破还有备胎——而不是因为它更快。

除非有合规要求指定 SHA-3，否则 SHA-256 或 BLAKE2b 都是更实际的选择。

短输入时，固定开销占主导

哈希表场景下 key 通常很短。16 字节输入的单次调用耗时：

算法                   ns/次     相对内置 hash()
------------------------------------------------
Python 内置 hash()     75.5 ns        1.00x
CRC32                 127.2 ns        1.68x
xxHash3-64            164.3 ns        2.18x
BLAKE2b               487.6 ns        6.46x
MD5                   612.0 ns        8.10x
SHA-256               715.8 ns        9.48x

注意这里的比例和大块数据完全不同：xxHash3 对 SHA-256 的优势从 18.8 倍缩到 4.4 倍。

因为短输入时，主要成本不是计算，是创建哈希对象、处理 padding、输出 digest 这些固定开销。在 Python 里还要加上一次方法调用和一次 bytes 对象分配。

所以「算法吞吐」这个指标只在大块数据上有意义。 哈希几百万个短 key 时，要看的是单次调用延迟。

密码哈希：故意慢 5 个数量级

PBKDF2-HMAC-SHA256 (10 万轮)     66.2 ms
scrypt (n=16384, r=8, p=1)       57.9 ms
对比: SHA-256 算一次 28 字节     ≈ 0.0002 ms

差了 30 万倍，这是设计目标，不是缺陷。

如果你用 sha256(password) 存密码，攻击者拿到库之后用一块消费级 GPU 每秒能试几十亿个——一个 8 位的常见密码几分钟就破了。

密码哈希函数的全部意义就是让每一次尝试都贵得离谱。而且 scrypt 和 Argon2 还额外要求大量内存，这样 GPU 和 ASIC 的并行优势也被抵消掉。

存密码只有三个正确答案：Argon2id、scrypt、bcrypt。 PBKDF2 是合规场景的最低底线（它只耗 CPU 不耗内存，对 GPU 不够友好）。任何裸 SHA / MD5 / 加盐 SHA 都是错的。

一张选型表

最后

哈希函数的选型，本质上是在回答一个问题：

你到底在防谁？

防传输时的比特翻转 → CRC32 够了。
防无意的碰撞 → xxHash 够了。
防有人故意构造碰撞 → 需要密码学哈希。
防有人拿着你的数据库慢慢暴力破解 → 需要故意很慢的算法。

而 MD5 的问题在于：它一个都不防，还不快。