bcrypt哈希值在MongoDB各版本间完全兼容，问题根源是认证机制升级：旧MONGODB-CR用户需重建为SCRAM-SHA-1，FCV须同步更新，驱动与连接字符串需显式指定authMechanism。
bcrypt 哈希结果在新旧 MongoDB 版本间完全兼容，问题不在哈希本身
密码哈希值（比如 bcrypt 生成的 $2a$10$... 字符串）是纯文本存储的，MongoDB 从 3.4 到 8.0 都把它当普通字符串字段处理，不解析、不校验、不转换。所以你用 bcrypt.hash() 算出来的值，存进 4.0、5.0 或 7.0 的 password 字段里，读出来也完全一样——这不是兼容性问题，而是常见误解。
真正出问题的地方：认证机制升级导致旧用户无法登录
升级 MongoDB 后“密码登不上”，90% 是因为服务端启用了更严格的认证机制，而旧用户是用老方式创建的，没适配新规则。典型现象是连接时抛出：MongoSecurityException: Exception authenticating MongoCredential{mechanism=SCRAM-SHA-1, ...} 或错误码 18。
- SCRAM-SHA-1 是 3.0+ 默认机制，但如果你是从 2.6 或早期 3.x 升级上来，老用户可能是用已废弃的
MONGODB-CR创建的，新版本服务器拒绝用该机制认证 - 用户创建时指定的
source（认证数据库）和实际连接时写的authSource不一致，比如用户在admin库创建，但连接字符串里写的是authSource=test -
featureCompatibilityVersion（FCV）没及时升级，比如卡在"3.6"，会导致新认证流程被禁用
验证并修复用户凭证的实操步骤
别急着重设密码，先确认问题根源：
- 连上新 MongoDB（关闭认证或用 root）：
mongosh --port 27017 - 查用户是否存在且机制正确：
use admin→db.system.users.find({user: "myuser"}).pretty()，重点看mechanisms字段是否包含"SCRAM-SHA-1" - 如果
mechanisms是["MONGODB-CR"]，说明用户是老方式建的，必须重建：db.dropUser("myuser")，再用新方式添加：db.createUser({user:"myuser", pwd:"xxx", roles:[{role:"readWrite", db:"mydb"}], mechanisms:["SCRAM-SHA-1"]}) - 检查 FCV：
db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})，如果不是目标版本（如升级到 5.0 后应为"5.0"），运行：db.adminCommand({setFeatureCompatibilityVersion: "5.0"})
驱动与连接字符串必须同步更新
Node.js 用 mongoose、Python 用 pymongo，如果驱动太老，可能默认发 MONGODB-CR 请求，或不支持 SCRAM-SHA-256（6.0+ 新增）。常见报错：Auth mechanism not specified 或连接直接被拒。
- 升级驱动：
npm install mongoose@7.0+（对应 MongoDB 6.0+）、pip install pymongo>=4.0 - 连接字符串显式指定机制（尤其跨大版本时）：
mongodb://user:pass@host:27017/db?authMechanism=SCRAM-SHA-1&authSource=admin - 避免混用：不要让一个应用同时连 3.6 和 6.0 实例，驱动很难兼顾两种认证握手流程
最常被忽略的一点：升级后，mongod 配置文件里的 security.authorization: enabled 虽然开了，但很多人忘了把旧用户删掉重建——旧凭证不会自动升级机制，它就静静地躺在 system.users 里，等着你第一次登录时给你一个精准的 18 错误。
