这种跨环境bcrypt哈希不匹配的坑我之前在老项目迁移时也踩过，哪怕两边bcrypt版本完全一致，也可能因为一些隐性差异导致验证失败。结合你的情况，我整理了几个最可能的原因和对应的解决思路：

1. 底层编译依赖或环境差异 #

Node.js v0.10.48是非常老旧的版本，它的V8引擎、libcrypto库和现代Meteor打包的Node环境可能存在细微差异——哪怕你安装了同版本的bcrypt，它在不同环境下编译时链接的底层库可能不一样，导致生成的哈希（尤其是盐的生成逻辑）出现偏差。

解决办法：

• 尝试在Meteor环境中完全复刻原Node v0.10.48的编译条件：比如使用nvm切换到v0.10.48，在Meteor项目目录下重新编译bcrypt，替换掉Meteor默认安装的版本。
• 如果是Linux环境，检查原Node环境的系统架构（x86/x64）、glibc版本，确保Meteor运行环境和它一致，避免二进制兼容问题。

2. 密码字符串的编码处理不一致 #

老版本Node.js的字符串默认编码和Meteor的字符串处理逻辑可能有隐性差异——比如原Node代码中直接传入字符串给bcrypt，而Meteor中可能隐式将字符串转换为了不同编码的Buffer，导致哈希的原始输入不一致。

解决办法：
在两端统一密码的处理逻辑，明确将密码转换为UTF-8编码的Buffer后再进行哈希/比对：

// 原Node.js端
const passwordBuffer = Buffer.from(userPassword, 'utf8');
const hash = bcrypt.hashSync(passwordBuffer, 10);
// 比对时
bcrypt.compareSync(Buffer.from(inputPassword, 'utf8'), storedHash);

// Meteor端同样使用相同逻辑
const passwordBuffer = Buffer.from(userPassword, 'utf8');
const isValid = bcrypt.compareSync(passwordBuffer, storedHashFromOldSystem);

3. Meteor的bcrypt封装层差异 #

Meteor可能对bcrypt做了一层封装（比如默认使用不同的bcrypt版本前缀，如$2b$而非原Node环境的$2a$），虽然bcrypt本身兼容不同版本前缀，但老版本的bcrypt可能存在解析问题。

解决办法：

• 先打印两端生成的哈希字符串，对比前缀是否一致（比如原Node的哈希是$2a$10$xxxxxxxx，Meteor生成的是不是同样的前缀）。
• 如果前缀不同，在Meteor中显式指定使用和原环境一致的bcrypt版本：

// 比如原环境用的是2a版本
bcrypt.hashSync(password, { version: '2a', rounds: 10 });

4. 系统环境变量影响字符处理 #

原Node环境的系统编码配置（如LC_ALL、LANG）和Meteor运行环境不一致，可能导致字符串转Buffer时出现编码错误。

解决办法：
在启动Meteor前，设置和原Node环境相同的环境变量，比如：

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
meteor run

快速验证步骤 #

1. 在原Node v0.10.48环境中，生成一个测试密码的哈希，比如bcrypt.hashSync('test123', 10)，复制这个哈希字符串。
2. 在Meteor环境中，直接用这个哈希字符串调用bcrypt.compareSync('test123', 复制的哈希)，看是否返回true。
3. 如果返回false，说明两端的compare逻辑或哈希解析有问题；如果返回true，则说明你迁移时的哈希存储/读取过程中出现了字符串篡改（比如多了空格、编码转换错误）。

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