bcrypt 同一个密码为什么生成不同结果：哈希、工作因子和校验操作

用 bcrypt 连续处理同一个密码，得到两串不同结果，是很多人第一次测试时会遇到的情况。正确的校验方法是把候选密码与保存的哈希交给比对流程，而不是重新生成一串，再直接比较两个字符串是否相等。

下面在 bcrypt 工具中完成两次生成、一次匹配和一次不匹配。演示字符串只用于公开测试，请勿用于真实账号。

先生成第一份哈希

打开 IT 工具中的“bcrypt加密”。在上方“输入字符串”中填写：

demo-only-Bcrypt!2026

保留当前默认的 Salt 轮数 为 10。输入后等待计算完成，哈希结果会自动出现。先复制这一次结果到临时测试记录里，后面用它进行校验。

本次结果以 $2b$10$ 开头，完整长度为 60 个字符。其中包含算法版本标识、工作因子，以及盐和计算结果所需的编码信息。保存时应保存完整字符串，不能只取看起来像随机内容的后一段。

页面名称中虽然使用“加密”一词，这里的操作实际生成的是密码哈希。工具没有从哈希还原原密码的“解密”步骤；下方的比对功能需要你提供一个候选字符串，判断它是否匹配。

不改内容，再生成一次

保留工作因子 10，清空上方输入后重新填写同一个演示字符串，等待第二份结果出现。两次结果的前缀一致，后面的内容却不同。

bcrypt 在生成时使用盐，因此同一个密码可以对应不同的哈希字符串。这种变化不能用于推断密码被改过，也不意味着第一份结果已经失效。不要把第二份哈希覆盖到业务数据库，只为了让它与某个样例字符串外观相同。

此时如果直接比较两份完整哈希，结论是“不相等”；但这回答的是两串文本是否相同，并没有完成密码校验。下一步应该使用工具的“字符串与哈希比对”。

用候选密码与已保存哈希比对

在下方“待比对字符串”填写原来的 demo-only-Bcrypt!2026，在“bcrypt 哈希”中粘贴第一份完整结果。计算后，“是否匹配”显示绿色的“匹配”。

保持哈希不变，只把候选字符串最后的 2026 改成 2027。本次显示红色的“不匹配”。这个对照说明，结果来自候选字符串与保存哈希的实际比对，而不是因为两边都有内容就默认通过。

复制哈希时不要加入前后空格，不要丢失开头的美元符号。出现“不匹配”时，先核对候选字符串的大小写、标点，以及哈希是否完整。比对结果只说明这一组输入的关系，不能证明某个真实账号已经通过了登录校验；工具没有连接你的账号系统。

Salt 轮数应怎样理解

页面把工作因子标注为 Salt 轮数。它是 bcrypt 的成本参数，不是把文本手动加盐多少次，也不应理解成只做了十次普通哈希。本次把它从 10 改为 8，生成结果的对应前缀变成 $2b$08$，说明这一参数写进了新哈希中。

工作因子越高，计算成本通常越高。界面显示的 0–100 是输入范围提示，不是建议把数值直接拉到最大；本文只实测了 8 和 10，没有验证所有数值都能在合理时间内完成。正式系统需要结合自己的服务端实现、并发量和响应时间确定参数。

用工具做联调时，保留一份完整哈希，再分别验证正确和错误候选字符串。需要调整成本参数时，明确区分新生成的测试哈希与此前保存的那一份，避免把“重新生成”和“校验”当成同一个操作。