上周有个做数据同步的朋友丢给我两个文件，说内容明明一模一样，跑出来的校验值却对不上，怀疑是传输过程被改过。我让他把两个文件都用二进制模式重新读一遍，问题当场就没了——一个是用文本模式打开的，换行符被悄悄转换了。这事儿特别典型：哈希算法本身没出错，出错的是喂给它的数据。哈希算法这个词听起来像是密码学课本里的东西，实际上它离日常开发非常近：下载安装包时那串校验码、数据库里存的用户口令、缓存集群的节点分配、版本控制工具里每个对象的编号、去重系统判断两个文件是不是同一份，背后全是它在干活。我写这篇东西，是想把哈希算法从“知道有这么个东西”讲到“能选、能用、能排错”：它是什么、有哪几条硬指标、主流算法该怎么选、四类真实用法分别要注意什么、参数怎么定、踩过的坑长什么样。刚接触的读者可以顺着读，把概念和代码一起过一遍；已经用过但心里没底的，可以直接跳到选型表和踩坑章节对照自己的项目。文中所有示例都是我按常见工程实践整理的可复现方案，参数取值给了推导过程，照着改就能用。

1. 先把哈希这件事说透：它到底解决什么问题

1.1 从一个“对不上”的校验值说起

哈希算法（Hash Function）做的事情，说白了就一句话：把任意长度的输入，压成一段固定长度的输出。你给它一个字节，它吐出 32 字节；你给它 10GB 的镜像文件，它还是吐 32 字节。这段输出通常叫摘要、散列值或者指纹。生活里最接近的类比是人的指纹：不管你是站着、坐着还是躺着，指纹就那一枚；两个人指纹相同的概率低到可以忽略；但你不能靠指纹反推出这个人长什么样、叫什么名字。哈希算法也是这三条性质：输入定死则输出定死、不同输入极难撞出同一个输出、从输出反推输入在计算上不可行。

回到开头那个“对不上”的例子。两个文件用文本模式读，Windows 下的\r\n会被转成\n，字节流变了，摘要自然就变了。这不是算法的问题，是输入被改造了。所以我一直跟人说，排查哈希相关的问题，第一步永远是确认“你算的到底是不是同一串字节”，而不是先去怀疑算法。这个顺序搞反了，能白折腾一下午。

哈希算法在工程里的价值，本质上是用一个极短的、可比对的字符串，去代表一份可能几十 GB 的数据。传输前算一次，落地后算一次，两个值相等就说明数据没被动过；口令存进数据库时算一次，登录时再算一次，两个值相等就说明密码对。它把一个“比对整份数据”的昂贵操作，换成了一个“比对 64 个十六进制字符”的廉价操作。

1.2 哈希函数的五条硬指标

不是我吹毛求疵，评估一个哈希算法能不能用在生产环境，我一般就看五条。第一条是输出定长，这是它能当“指纹”用的前提，输出长度飘忽就没法做定长索引和比对。第二条是确定性，同一个输入在任何机器、任何时间、任何语言实现下都必须得到同一个结果，否则跨系统协作就崩了。第三条是抗第一原像性，也就是给定摘要值，反推原始输入在算力上做不到——这条决定了口令哈希有没有意义。第四条是抗第二原像性，给定输入 m1，找一个不同的 m2 让两者摘要相同，做不到；这条在文件校验场景里最关键，攻击者不能拿一个恶意文件去顶替你信任的那个。第五条是抗碰撞性，随便找两个不同输入让它们摘要相同，同样做不到。第四条和第五条看着像，实际难度不一样，碰撞攻击通常比第二原像攻击容易得多，所以一个算法的“抗碰撞强度”往往是最先被攻破的那一环。

除了这五条，还有两个工程上很在意的性质。雪崩效应：输入只改一个比特，输出应该有接近一半的比特发生变化。你可以自己试一下，把abc改成abd，SHA-256 的结果看上去完全是两串无关的乱码，这就是合格的雪崩效应。计算效率：同一个安全等级下越快越好，因为校验大文件、算缓存键都是高频操作，慢一倍就是成本翻倍。

这里要提一句强度估算。n 位输出的哈希，暴力碰撞的期望复杂度大约是 2^(n/2)，这是生日悖论带来的结果，不是 2^n。所以 256 位输出的抗碰撞强度实际是 128 位，这个数量级目前足够用；128 位输出的抗碰撞强度只有 64 位，用今天的算力去凑是可行的，这就是 MD5 不能再用于安全场景的根本原因。

1.3 三个最容易被混淆的概念：哈希、加密、编码

这三个东西混着说，是我见过最多的问题源头。哈希是单向的，算完就回不去了，你只能拿另一个输入再算一次去比对。加密是双向的，有密钥就能还原明文，它的目的是保密而不是比对。编码是可逆的映射，比如 Base64，谁都能解开，它只是为了跨协议传输时把二进制转成文本，一点保密性都没有。把口令做 Base64 存起来当“加密”用，是新手最常犯的错之一，等于没处理。

还有一个容易混的点：加盐哈希不等于加密。盐是一个随机串，和口令拼在一起再哈希，目的是让相同的口令在不同用户那里得到不同的摘要，挡住彩虹表和批量撞库。盐本身不需要保密，通常和摘要存在一起，它防的不是“单个口令被反推”，而是“一次算表打穿一片”。

注意：判断一段代码有没有安全处理口令，只看一个特征——数据库里同一个密码的两个用户，存的摘要是不是不一样。如果一样，那就是没加盐或者盐是全局固定的，基本等于裸奔。

2. 主流算法横向拆解与选型逻辑

2.1 MD5 和 SHA-1：为什么今天只能当“体检报告”用

MD5 输出 128 位，SHA-1 输出 160 位，两者都是上世纪的设计，内部都是 Merkle–Damgård 结构：把消息分块，一块一块地压进一个固定大小的状态里，最后输出状态。这个结构简单、快、实现容易，所以当年铺得极广。问题是它们的抗碰撞性已经被实际攻破——MD5 的碰撞早就不需要什么超级算力，普通机器几秒钟就能构造出一对摘要相同的不同文件；SHA-1 的碰撞实例也已经在公开场合展示过，成本被压到了可控范围。

那它们还能不能用？我的答案是：看用途，不看心情。做非安全场景的快速指纹，比如给缓存键生成一个短标识、给日志行做个去重标记、给临时文件名加个后缀，MD5 依然好用，因为它快、短、生态全。但只要是“防篡改”和“防伪造”的场景，一律不能用：文件完整性校验、软件发布校验、数字签名、证书、口令存储，这五类场景里出现 MD5 或 SHA-1，我会直接标成缺陷。

有人会问，那我加个盐再用 MD5 行不行？不行。加盐解决的是“相同输入得到相同输出”带来的批量撞库问题，解决不了算法本身碰撞容易构造的问题。这两件事是正交的，不能互相替代。

提示：如果你接手的老系统里用 MD5 存口令，迁移方案通常是“双写”——登录时用 MD5 校验通过后，顺手用新算法（bcrypt 或 Argon2id）算一份存进去，等存量用户陆续登录完成自然切换，最后再统一清掉旧字段。别指望一次性全量重算，因为原始口令你根本拿不到。

2.2 SHA-2 家族：工程上最不容易出错的一档

SHA-2 是一组算法：SHA-224、SHA-256、SHA-384、SHA-512，还有 SHA-512/224、SHA-512/256 这类截断变体。日常用得最多的是 SHA-256，输出 256 位即 32 字节，十六进制表示 64 个字符。它的抗碰撞强度按 2^128 算，目前没有任何实用攻击路径，所以我给绝大多数项目的默认建议就是它——不管你是做文件校验、做摘要索引还是做 HMAC，SHA-256 都是那个“选了不会错”的选项。

SHA-512 在 64 位机器上其实比 SHA-256 更快，因为它内部字长是 64 位，跟寄存器宽度对得上，而 SHA-256 用的是 32 位字。这点很多人不知道，以为位数越多越慢。实测在常见的 x86-64 服务器上，处理大文件时 SHA-512 的吞吐经常略高于 SHA-256。当然摘要更长，存储和传输成本会上去一点，做索引键的时候要考虑字段长度。

SHA-2 有个结构性弱点叫长度扩展攻击：因为 Merkle–Damgård 结构在收尾时把消息长度附在末尾，知道H(m)和len(m)的人，可以在不知道 m 的情况下算出H(m || padding || 附加数据)。这个性质本身不是“碰撞”，但在某些把哈希直接当 MAC 用的错误设计里会被利用。正确的做法是用 HMAC，或者干脆用 SHA-3 这类不受影响的结构。所以我一直强调：不要把H(key || message)当消息认证码用，那不是 HMAC，那是给攻击者留门。

2.3 SHA-3 与 BLAKE 系列：换结构带来的实际差异

SHA-3 是新一代标准，内部结构叫海绵结构（Sponge），跟 SHA-2 完全是两条路子：先用一个置换函数把数据“吸”进状态，再“挤”出摘要。这个结构天生不受长度扩展攻击影响，也不需要像 SHA-2 那样做消息长度填充。代价是纯软件实现下速度通常不如 SHA-256，虽然有硬件指令支持后会好很多，但在通用服务器上，SHA-3 一般不是性能首选。

BLAKE2 和 BLAKE3 是另一条线上的产物，主打速度。BLAKE2b 在 64 位平台上处理大文件的吞吐能明显超过 SHA-256，而且有原生的密钥模式和并行能力；BLAKE3 更进一步，基于 Merkle 树做并行，多核下几乎线性加速，适合大文件校验、内容寻址存储这类场景。我在做本地大文件去重的时候用过 BLAKE3，一个几 GB 的镜像，多线程下算摘要的时间基本可以忽略。

不过选型不能只看速度。跨系统协作时优先选对方也有的算法，SHA-256 几乎无处不在，BLAKE3 在很多老环境里还得额外装库。我的判断逻辑是：对外交付、需要长期验证的东西用 SHA-256；内部高频、纯性能敏感的大文件处理可以考虑 BLAKE 系列；需要抵抗长度扩展又不想引入 HMAC 的场景，SHA-3 是个干净的选择。

2.4 一张选型对照表

光讲道理没用，直接上表。下面这张表是我自己项目里常用的对照，参数都是按通用场景给的，实际项目按合规要求和性能预算调整。

口令场景要单独拎出来，因为那些不是普通哈希，是慢哈希 / 密钥派生函数：

注意：这张表里的“耗时”是刻意设计的，不是缺点。口令哈希的理想状态就是慢到攻击者撞不动、快到用户察觉不到，一般定在 100 毫秒上下比较平衡。如果你的口令哈希只要 1 毫秒，那说明参数定得太低，等于给撞库开了绿灯。

3. 哈希在系统里的四类真实用法

3.1 完整性校验：从下载包到数据库迁移

这是哈希最朴素也最广的用法。发布一个安装包，同时给出 SHA-256 值；用户下载后本地算一遍，对上就用。这个流程的关键不在算法，在于校验值本身的可信来源——如果校验值和安装包放在同一个页面、同一个服务器上，被同时替换的可能性就存在，那校验的意义会打折。工程上通常是把摘要值写进发布说明、写进独立的签名文件，或者直接对摘要再做一次数字签名，这样才闭环。

做数据库迁移的时候我也常用这招。几百万行数据从 A 库搬到 B 库，怎么确认没丢没串？我会在迁移前后各算一次“整表摘要”：按主键排序，把每行的关键字段拼成一个规范化字符串，逐行喂进 SHA-256，最后得到一个值。两边一致就说明内容对得上。这里有个细节必须注意：拼接要加分隔符，否则("ab", "c")和("a", "bc")会拼成同一个字符串，摘要相同但数据不同。我一般用\x1f这种不可能出现在业务字段里的控制字符做分隔。

还有一个更隐蔽的坑：字段顺序和空值表示。SQL 查询不写 ORDER BY，返回顺序是不保证的；NULL和空字符串在拼接时如果都变成空，就会掩盖差异。所以规范化函数里我会显式把 NULL 写成\N，把所有字段按固定顺序拼。这类细节不写清楚，校验值就只是个心理安慰。

3.2 口令存储：加盐、慢哈希与参数怎么定

口令存储是整个哈希话题里最容易出事的地方。核心原则三条：用慢哈希、每个用户独立盐、参数可升级。

先说盐。盐是每个用户注册时生成的随机字节串，长度 16 字节足够。它和口令拼接后一起进哈希函数，结果和盐一起存库。盐的作用是让相同口令产生不同摘要，挡住预计算表和批量撞库。盐不需要保密，也不需要加密存储，因为它的价值在于唯一性而不是机密性。我见过把盐写成全局常量的实现，那基本等于没加。

再说慢哈希。MD5、SHA-256 这类通用哈希设计目标是快，一秒能算上亿次，正好方便攻击者暴力枚举。所以口令场景要用专门设计的函数：bcrypt、scrypt、Argon2id，或者标准兼容性优先时用 PBKDF2。它们靠三件事拖慢攻击者——迭代次数（多算几万轮）、内存占用（scrypt 和 Argon2 会吃掉大量内存，让 GPU 和专用硬件的并行优势下降）、并行度参数。

参数怎么定？我的做法是先测。在本机跑一次哈希，测量耗时，调整参数到 100 毫秒左右。以 Argon2id 为例，常见的起点是内存 64MB、迭代 3 次、并行度 4，然后根据机器性能上下调。bcrypt 的话 cost 从 10 开始，每加 1 耗时翻倍，12 在多数服务器上大约是 200~300 毫秒，我一般用 10 或 11。PBKDF2 的迭代次数按当前年份的推荐值走，六十万次是个常见的下限。

参数还有一个隐性问题：参数要跟着摘要一起存。因为算法和参数会随时间升级，老用户的摘要还是老参数算的，登录时要能用当时的参数验证。所以数据库字段里通常存的是完整的编码串，比如 bcrypt 的$2b$12$...里就带了版本和 cost，Argon2 的编码串里带了内存、迭代、并行度和盐值。自己拼字段也行，但别只存那串十六进制摘要，否则以后没法平滑升级。

3.3 哈希表与一致性哈希：数据结构的底座

哈希在数据结构里的角色完全不同：这里不追求抗碰撞，追求的是均匀分布和常数时间查找。哈希表的原理是把键哈希成一个整数，对桶数量取模，落到某个桶里。桶数量是有限的，键是无限的，所以碰撞必然发生，关键在于怎么处理。

两种主流方案：链地址法把同一个桶的元素串成链表，冲突多了链表变长，查找退化；开放寻址法在冲突时按规则往后探测空位，缓存友好但删除麻烦，需要墓碑标记。工程实现一般会在链表长度超过阈值（比如 8）时转成红黑树，把最坏情况从 O(n) 拉到 O(log n)。

比冲突处理更重要的是扩容。元素越装越满，负载因子（元素数 / 桶数）升高，碰撞变多，性能下降。常见阈值是 0.75，超过就扩容，一般是桶数翻倍，然后把所有元素重新哈希分布。这个“全部重算”的操作代价很大，所以有些实现会做渐进式扩容，每次操作顺带搬一部分。这也解释了一个现象：往哈希表里连续插入大量元素时，偶发的长尾延迟往往不是插入本身慢，而是某次插入触发了扩容。

一致性哈希解决的是另一个问题：节点会变。普通取模哈希，节点数从 3 变成 4，几乎所有键的归属都会变，缓存大面积失效。一致性哈希把哈希值空间首尾相接成一个环，节点和键都映射到环上，键顺时针找到的第一个节点就是它的归属。增删一个节点，只影响环上相邻的一段，其他键不动。

但基础版一致性哈希有个毛病：节点少的时候，环上分布很不均匀，可能某个节点扛了 60% 的键。解决办法是虚拟节点：每个物理节点在环上放 150 到 200 个虚拟副本，键落到虚拟节点上再映射回物理节点。副本越多分布越均匀，但内存和查找开销也上升。我一般用 160 个，实测分布偏差已经可以接受。

3.4 消息认证码与数字签名：哈希在密码学里的位置

哈希单独用只能保证“完整性”，不能保证“来源”。攻击者改完数据顺手重算一次摘要，你照样被骗。要防这个，就需要引入密钥，这就是 HMAC（基于哈希的消息认证码）。

HMAC 的构造很巧妙，它不直接用H(key || message)，而是做两次哈希，用两个由密钥派生出来的固定填充值：

HMAC(K, m) = H( (K' ⊕ opad) || H( (K' ⊕ ipad) || m ) )

其中 K' 是把密钥补齐或哈希到分组长度，ipad 和 opad 是两个固定的常量字节。这个双层结构挡住了长度扩展攻击，也让密钥不会直接暴露在压缩函数的输入里。日常用它校验接口回调、校验内部服务间的请求体，都是标准做法。校验时一定要用恒定时间比较，别用普通的字符串相等，否则理论上可以被时序侧信道逐字节猜出来。

数字签名则是另一层：先用哈希把消息压成摘要，再用私钥对摘要签名，验证方用公钥验签再自己算一遍摘要比对。这里哈希的作用是“把任意长的消息变成固定短的、可被签名算法处理的东西”。这也是为什么签名的安全性直接依赖于哈希的抗碰撞性——如果能构造出两个摘要相同的不同文档，就能让一份签名同时“签”了两份内容。SHA-1 退出签名场景，根子就在这里。

4. 动手实操：命令行、代码与参数

4.1 命令行先跑通：几个常用姿势

排查问题的时候，命令行是最快的。Linux 和 macOS 上直接用sha256sum：

# 计算单个文件 sha256sum package.tar.gz # 生成校验清单，之后用 -c 批量验证 sha256sum *.tar.gz > SHA256SUMS sha256sum -c SHA256SUMS

macOS 上没有sha256sum，用shasum -a 256，或者openssl dgst -sha256。后者跨平台性更好：

openssl dgst -sha256 package.tar.gz

Windows 上自带的certutil也能算：

certutil -hashfile package.zip SHA256

要验证“我算的和对方给的是不是同一个东西”，脚本里别直接diff人眼比对，注意两个细节：一是有些工具输出带文件名，有些纯十六进制，格式先统一；二是大小写敏感问题，十六进制摘要比较前统一转小写。这两点看起来幼稚，但我在三四个项目里见过因为这两个原因误判“校验失败”的。

4.2 Python 里做文件校验和口令处理

做文件校验时最常犯的错是把整个文件读进内存。f.read()在大文件上会直接把进程撑爆。正确做法是分块流式读取，块大小 64KB 到 1MB 都行：

import hashlib def file_sha256(path, chunk_size=1024 * 1024): h = hashlib.sha256() with open(path, "rb") as f: # 必须是二进制模式 while True: block = f.read(chunk_size) if not block: break h.update(block) return h.hexdigest()

open的"rb"是重点，文本模式会做换行符转换和编码转换，算出来的摘要跟别人对不上。这就是开头那个案例的根因。块大小我一般取 1MB，太小系统调用多，太大内存占用高，1MB 在大文件上表现比较平衡。

HMAC 的写法，注意用hmac.compare_digest做比较：

import hmac, hashlib def sign(payload: bytes, key: bytes) -> str: return hmac.new(key, payload, hashlib.sha256).hexdigest() def verify(payload: bytes, key: bytes, received: str) -> bool: expected = sign(payload, key) return hmac.compare_digest(expected, received)

口令处理用 Argon2id，需要装argon2-cffi：

from argon2 import PasswordHasher from argon2.exceptions import VerifyMismatchError ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4) def hash_password(raw: str) -> str: return ph.hash(raw) # 盐自动生成并编码进结果串 def check_password(stored: str, raw: str) -> bool: try: return ph.verify(stored, raw) except VerifyMismatchError: return False

memory_cost的单位是 KB，65536 就是 64MB。这个值直接决定了内存占用，如果你的服务单机有几百个并发登录，得把 64MB 乘以并发数算一下峰值内存，别把数据库服务器压垮。这是实践里最容易忽略的一笔账：慢哈希的“慢”是有代价的，代价会体现为 CPU 和内存压力。

4.3 手写一个带虚拟节点的一致性哈希

不依赖第三方库，用标准库就能写一个够用的版本。核心是把环上的位置做二分查找：

import hashlib import bisect class ConsistentHash: def __init__(self, nodes=None, replicas=160): self.replicas = replicas self._ring = [] # 排序后的哈希位置 self._map = {} # 位置 -> 节点名 for n in (nodes or []): self.add(n) def _hash(self, key: str) -> int: return int.from_bytes( hashlib.sha256(key.encode()).digest()[:4], "big" ) def add(self, node: str): for i in range(self.replicas): pos = self._hash(f"{node}#{i}") self._ring.append(pos) self._map[pos] = node self._ring.sort() def remove(self, node: str): for i in range(self.replicas): pos = self._hash(f"{node}#{i}") if pos in self._map: del self._map[pos] idx = bisect.bisect_left(self._ring, pos) self._ring.pop(idx) def get(self, key: str) -> str: if not self._ring: return None pos = self._hash(key) idx = bisect.bisect_left(self._ring, pos) if idx == len(self._ring): idx = 0 return self._map[self._ring[idx]]

取前 4 字节转整数，得到 32 位空间，环的大小是 2^32。这里用 SHA-256 而不是 MD5 纯粹是习惯，一致性哈希对密码学强度没要求，用 MD5 甚至 CRC32 都行，只要分布均匀。测试分布是否均匀的方法很土但有效：造一万个随机键，统计每个节点分到多少，偏差在 ±10% 以内我就认为可以。虚拟节点用 160 个的时候，实测偏差通常在 5% 左右，够用了。

4.4 哈希表的扩容与冲突处理实测

想真正理解负载因子为什么是 0.75，最好的办法是自己写一遍。下面是个链地址法的简化实现，重点是扩容逻辑：

class SimpleMap: def __init__(self, capacity=8, load_factor=0.75): self.capacity = capacity self.load_factor = load_factor self.size = 0 self.buckets = [[] for _ in range(capacity)] def _index(self, key): return hash(key) % self.capacity def put(self, key, value): idx = self._index(key) bucket = self.buckets[idx] for i, (k, v) in enumerate(bucket): if k == key: bucket[i] = (key, value) return bucket.append((key, value)) self.size += 1 if self.size / self.capacity > self.load_factor: self._resize() def get(self, key, default=None): idx = self._index(key) for k, v in self.buckets[idx]: if k == key: return v return default def _resize(self): old = self.buckets self.capacity *= 2 self.buckets = [[] for _ in range(self.capacity)] self.size = 0 for bucket in old: for k, v in bucket: self.put(k, v)

跑一遍就能直观看到：容量 8 的时候插入第 7 个元素会触发扩容，所有元素重算位置，这一次插入的耗时明显高于平均。这就是所谓“尾延迟尖刺”的来源。0.75 这个阈值是时间与空间的折中：定得太高，链表变长查询变慢；定得太低，扩容频繁而且内存浪费。这个数字在多数通用实现里都能跑到接近最优，不用自己调。

5. 踩坑记录与排查速查表

5.1 校验类问题的排查顺序

校验值对不上，别急着怀疑算法，按这个顺序走基本三分钟内能定位。第一，确认两边算的是不是同一份字节：文件是不是文本模式读的、有没有 BOM、有没有换行符转换、有没有解压过、有没有被中间层加了个头。第二，确认算法和参数一致：有 SHA-256 有的 SHA-256/224，有十六进制小写有大写，有大端小端拼接差异。第三，确认截取长度：有些系统只存摘要前 8 位做展示，你拿全量去比当然不等。第四，确认编码：摘要本身是二进制还是十六进制字符串，二进制再转一次 Base64 就完全变了。

还有一个特别隐蔽的：拼接顺序。做多字段联合校验时，A 系统拼id + name，B 系统拼name + id，摘要必然不同。所以我会把规范化规则写成文档，明确字段顺序、分隔符、空值表示、编码格式，这四个要素缺一不可。团队里换人之后，这文档能省下无数扯皮。

5.2 口令相关的三个典型坑

第一个坑是用了快哈希。SHA-256 直接算一次存库，看着比明文强，实际上在现代硬件上每秒能试上亿次，八位口令的搜索空间根本撑不住。第二个坑是盐不唯一。全局固定盐或者用用户 ID 当盐，都能被彩虹表打穿，尤其是盐值可预测的时候。第三个坑是参数不可升级。系统上线时 bcrypt cost 定了 8，五年后算力涨了几十倍，但字段里只存了摘要没存参数，想升级只能等用户改密码。所以字段设计一开始就要留好，存完整编码串，别自己拍脑袋拆。

还有一个不太被提起的问题：口令长度上限。bcrypt 只处理前 72 字节，超出的部分被静默忽略。如果你的用户设了一个 100 字符的密码，实际上只有前 72 字节生效，后面的随便输都能登进去——这既是安全弱化，也是用户体验灾难。用 Argon2 或者 PBKDF2 就没这个问题，或者提前在业务层做长度限制并给出提示。

提示：验证口令的接口一定要做频率限制和失败计数。慢哈希只是提高了单次尝试的成本，挡不住无限次尝试。这两层是配合关系，缺一层效果都会打对折。

5.3 性能与并发相关的坑

第一个是大文件摘要占满 CPU。一个几百 GB 的备份文件，单线程算 SHA-256 要好几分钟，期间一个核跑满。解决办法是分块并行加树形合并，或者换支持并行的算法。BLAKE3 这个方向做得比较彻底，多核下能接近线性加速。不过要注意，并行算出来的结果必须和单线程结果一致，否则跨系统的校验值就对不上了，选算法时得确认这一点。

第二个是慢哈希拖垮登录接口。前面提过，Argon2 每次 64MB 内存，并发高了内存直接打满。我的做法是把登录接口的口令校验放到独立的线程池或者独立服务里，限制并发数，超出的排队或者快速失败。宁可让用户多等一秒，也不要让整个服务雪崩。

第三个是哈希表在并发下的退化。多线程同时插入触发扩容，很容易出问题；有些实现干脆加全局锁，吞吐就下来了。这种场景要么用分段锁，要么用无锁结构，要么老老实实按线程分片。这块的具体选择跟语言和运行时关系很大，我不太建议自己造轮子，用成熟实现更稳。

5.4 问题速查表

把上面这些整理成一张表，出问题时按行对照，比翻文档快：

最后分享一个我在实际项目里养成的小习惯：所有对外提供校验值的地方，都在摘要旁边明确写出算法名和编码格式，比如sha256:9f86d08...，而不是光秃秃一串十六进制。这个前缀看着多余，但能省掉后续无数次“你这算的是哪个算法”的沟通。同理，凡是入库的口令摘要，一定存完整编码串而不是裸摘要，把算法、参数、盐全带上。这两个习惯没什么技术含量，纯粹是把未来可能的麻烦提前掐掉——踩过的坑多了，就会明白大部分故障不是因为算法不够强，而是因为信息在交接的时候丢了一点点。