Node.bcrypt.js 中哈希值不一致问题的分析与解决

问题现象

在使用Node.bcrypt.js进行密码哈希处理时，开发者遇到了一个奇怪的现象：当将生成的哈希值赋值给变量后再存入数据库，最终存储的哈希值与最初生成的哈希值不一致。具体表现为：

1. 直接输出bcrypt.hash()生成的哈希值是一个结果
2. 将该哈希值赋给变量后再存入数据库，数据库中存储的却是另一个不同的哈希值
3. 直接赋值给模型属性而不经过变量中转时，哈希值保持一致但验证仍然失败

问题根源

经过深入分析，这个问题实际上是由Mongoose的中间件机制引起的。当开发者使用userSchema.pre('save')注册了一个保存前的钩子函数时，每次调用user.save()方法都会触发这个钩子函数。

关键在于：这个钩子函数会在每次保存操作时重新执行密码哈希，即使密码已经被哈希过。这就导致了以下情况：

1. 开发者手动调用bcrypt.hash()生成哈希值
2. 将该哈希值赋给用户对象的password属性
3. 调用user.save()时，pre-save钩子再次触发，对已经哈希过的密码进行二次哈希
4. 最终存入数据库的是二次哈希后的结果

解决方案

方案一：条件哈希

最可靠的解决方案是在pre-save钩子中添加条件判断，只有当密码被修改时才进行哈希：

userSchema.pre('save', async function() {
    if (!this.isModified('password')) return;
    
    const salt = await bcrypt.genSalt(10);
    this.password = await bcrypt.hash(this.password, salt);
});

这种方法利用了Mongoose提供的isModified()方法，确保只在密码实际发生变化时才执行哈希操作。

方案二：避免双重哈希

如果确实需要在代码中手动哈希密码，可以暂时禁用pre-save钩子：

// 手动哈希密码
const hashpassword = await bcrypt.hash(password, salt);
user.password = hashpassword;

// 保存时不触发pre-save钩子
await user.save({ validateBeforeSave: false });

不过这种方法不够优雅，推荐优先使用方案一。

最佳实践

1. 始终使用pre-save钩子处理密码哈希：将密码哈希逻辑集中放在模型定义中，避免分散在业务代码里
2. 添加修改检查：使用isModified()确保不会重复哈希
3. 测试验证逻辑：确保比较函数能正确处理存储的哈希值
4. 合理设置字段长度：虽然bcrypt哈希值长度固定(60字符)，但建议设置为更宽松的长度限制(如100字符)以适应未来可能的算法变化

总结

Node.bcrypt.js与Mongoose结合使用时，pre-save钩子的执行机制可能导致意外的双重哈希问题。通过理解Mongoose的中间件生命周期和添加适当的条件判断，可以确保密码哈希的一致性和正确性。这种模式不仅适用于密码哈希，也适用于其他需要在保存前进行数据转换的场景。