使用bcrypt哈希令牌时相同明文哈希值不一致问题排查

核心问题是对bcrypt的参数逻辑和设计机制理解错误：

• bcrypt的第二个参数传入数字时，仅代表密钥派生的cost迭代轮次（传入0代表迭代次数为2^0=1轮），没有任何关闭自动加盐的作用。作为专门为密码存储设计的慢哈希算法，bcrypt默认强制每次哈希生成128位随机盐，和轮次参数无关。
• bcrypt的输出结构固定为$2b$[cost]$[22位随机盐][31位哈希结果]，随机盐会直接拼接在最终哈希串中。因此哪怕明文、cost参数完全一致，只要两次调用bcrypt.hash()生成的随机盐不同，输出的哈希值就不可能相等，自然无法直接作为数据库等值查询的条件。
• “高熵全局唯一令牌不需要额外加盐”的判断本身是合理的，但bcrypt天生适配的是“需要随机盐抗彩虹表、不需要固定输出”的密码存储场景，完全不匹配你需要确定性哈希做查询的需求。

不需要强行改造bcrypt，换用适配场景的哈希算法即可：

• 选用SHA-256这类无随机盐、相同输入固定输出的快速安全哈希算法，安全要求更高可以配置服务端全局密钥使用HMAC-SHA256——即使数据库被拖库，攻击者没有服务端密钥也无法伪造有效令牌的哈希值。
• 实现逻辑分为两步：
  • 令牌生成阶段：用crypto.randomBytes(16).toString('hex')生成明文令牌后，调用crypto.createHash('sha256').update(tokenSecret).digest('hex')计算哈希值存入数据库，不存明文。
  • 令牌校验阶段：拿到请求携带的明文令牌后现场计算SHA-256哈希，直接以_userId + 令牌哈希为条件做单条数据库查询，命中即校验通过，全程不需要遍历数据、不需要多次bcrypt比对，性能开销极低。
• 补充说明：最初的校验方案其实没有“遍历全库性能极差”的问题——已经拿到userId的前提下，只需要查询对应用户名下的有效令牌即可，正常业务中单个用户同时生效的密码重置、邮箱验证类令牌最多1_{2条，bcrypt比对1}2次的性能完全可以接受，只是上述固定哈希查询的方案效率更高。

注意：不要尝试通过给bcrypt传入固定自定义盐的方式实现确定性哈希，这种用法会废掉bcrypt原有的抗暴力破解、抗彩虹表设计优势，性能也远不如直接用SHA-256，没有任何实用价值。

内容的提问来源于stack exchange，提问作者lpares12