MongoDB 4.0强制弃用MONGODB-CR，因其彻底移除认证流程、authSchemaUpgrade命令及copydb等CR兼容逻辑；若3.6中仍存CR用户，4.0启动将报Authentication failed或UserNotFound错误，导致mongod初始化失败，故必须在升级前于3.6环境下手动执行db.updateUser升级至SCRAM-SHA-1并更新驱动连接参数。
MongoDB 4.0 强制弃用 MONGODB-CR，所有新用户必须使用 SCRAM；已有 MONGODB-CR 用户无法直接升级到 4.0，必须提前迁移。
为什么升级前必须手动迁移鉴权机制
4.0 彻底移除了对 MONGODB-CR 的支持，包括认证流程、authSchemaUpgrade 命令、copyDatabase() 和 copydb 中的 CR 兼容逻辑。如果你在 3.6 实例中仍存在 MONGODB-CR 用户（比如从 2.6 升级而来且未主动升级），4.0 启动时会直接拒绝加载这些用户，日志中抛出 Authentication failed 或 UserNotFound 错误，mongod 进程可能无法完成初始化。
迁移不是“自动发生”的——它必须在升级前、以 3.6 实例运行状态下完成：
- 确认当前用户认证机制：
db.system.users.find({ mechanisms: "MONGODB-CR" }) - 逐个升级用户：执行
db.updateUser("username", { mechanisms: ["SCRAM-SHA-1"] })（注意：不能用authSchemaUpgrade，该命令在 4.0 已被删除） - 验证升级结果：
db.system.users.findOne({ user: "username" }).mechanisms应返回["SCRAM-SHA-1"] - 确保所有驱动连接字符串已更新为显式指定
authMechanism=SCRAM-SHA-1（旧驱动默认不发此参数，易连上但鉴权失败）
SCRAM-SHA-1 与 MONGODB-CR 的实际行为差异
SCRAM 不是简单换了个名字的“增强版 CR”，它重构了整个握手流程，影响连接建立、凭证存储和中间件兼容性：
- MONGODB-CR 使用单次 MD5 挑战响应，密钥派生无 salt、无迭代，凭证以
pwd字段明文存于system.users（哈希后）；SCRAM 将 salt、iterationCount 存入用户文档，credentials字段结构完全不同 - SCRAM 握手需 3 轮往返（client-first → server-first → client-final），比 CR 多一次 RTT；高延迟网络下首次连接耗时略增，但可缓存
CombinedNonce减少后续开销 - 客户端若未正确实现 SCRAM（如某些老旧 Python PyMongo Authentication failed，无机制提示
- SCRAM 支持
SCRAM-SHA-256（4.0+ 可配，但需客户端支持），而 MONGODB-CR 根本不支持 SHA-256
升级后连接失败的典型排查点
即使用户已升级为 SCRAM，生产环境仍常因配置错位导致连接中断，重点检查以下几处：
- 驱动版本是否 ≥ 对应语言的最低要求（例如：Java Driver 3.11+、PyMongo 3.7+、Node.js mongodb 3.0+）
- 连接字符串是否遗漏
authMechanism=SCRAM-SHA-1？尤其当 MongoDB URI 中含authSource=admin却没带机制时，部分驱动会默认尝试 MONGODB-CR - 副本集配置中，
members[n].user若引用的是旧 CR 用户，rs.status()会显示stateStr: "STARTUP2"卡住，日志报Failed to authenticate with member - 云服务（如阿里云、腾讯云 MongoDB）控制台可能缓存旧连接模板，需手动刷新或重置连接串，不能直接复用 3.6 时代的 URI
最易被忽略的是：SCRAM 要求服务器和客户端对 iterationCount 达成一致，而这个值在用户升级时由服务端生成并写入凭证。如果用 mongodump/mongorestore 在 3.6 和 4.0 间迁移用户数据，system.users 集合不能直接复制——必须通过 db.updateUser() 重建，否则 salt 和 iterationCount 缺失，SCRAM 握手必然失败。
