嘿，这其实不是bug，而是bcrypt故意设计成这样的！

你遇到的这个“慢”，恰恰是bcrypt作为密码哈希算法的核心优势所在——它就是为了让暴力破解变得无比困难才这么做的。具体原因可以拆解成这几点：

• 自适应哈希的设计初衷：bcrypt属于自适应密码哈希函数，它的核心目标是对抗暴力破解攻击。暴力破解需要攻击者反复尝试成千上万的密码组合，而bcrypt通过故意增加计算耗时，直接拉高了攻击者的破解成本——哪怕用高性能GPU集群，每秒能尝试的密码数量也会被大幅压缩。
• 工作因子（Cost Factor）的影响：你看你用的哈希值$2a$14$RWV9NhWmlQmSoV9toM/k9OIzaNcYssCiauPVAljiX2NGhqvyxcOMy，其中的14就是工作因子。这个数值决定了哈希计算的迭代次数：工作因子每增加1，计算时间就会翻倍。你用的14已经是中等偏高的数值了，对比默认的10，耗时会是它的16倍（2^(14-10)=16）。
• 比对过程的计算量：CompareHashAndPassword的工作逻辑是，用输入的密码，结合哈希值里记录的盐值和工作因子，重新执行一遍哈希计算，再和存储的哈希结果比对。所以这个过程的耗时和生成该哈希时的耗时是几乎一致的，自然会比较久。

一些小建议 #

如果这个耗时已经影响到你的业务体验，可以考虑：

• 适当降低工作因子（比如调到12），但要注意：工作因子越低，破解难度也会随之降低，需要在安全性和性能之间找到平衡。
• 行业内一般建议把单次哈希/比对的耗时控制在100-200毫秒左右，这样既不会让用户有明显的等待感，又能保持足够的安全门槛。

附上你的测试代码：

var b []byte = []byte("1234")
var bx []byte = []byte("$2a$14$RWV9NhWmlQmSoV9toM/k9OIzaNcYssCiauPVAljiX2NGhqvyxcOMy")
fmt.Println("Start Compare: ", time.Now().Format("2006-01-02 15:04:05.000000"))
err := bcrypt.CompareHashAndPassword(bx, b)
fmt.Println("Completed Compare: ", time.Now().Format("2006-01-02 15:04:05.000000"))
fmt.Println("------------------------")

内容的提问来源于stack exchange，提问作者A.kadir olmez