SCRAM-SHA-256是MongoDB 4.0+默认认证机制，要求服务端哈希密码，兼容2024年后各官方驱动；SCRAM-SHA-1仅用于旧版Navicat等不支持SHA-256的客户端，需服务端强制降级配置。
SCRAM-SHA-1 和 SCRAM-SHA-256 的实际兼容性差异
现在（2026年）绝大多数 MongoDB 服务端默认启用 SCRAM-SHA-256，且云数据库已完全弃用 MONGODB-CR；但 SCRAM-SHA-1 仍被部分旧版驱动或遗留系统支持，不是“不能用”，而是“不该主动选”。
-
SCRAM-SHA-256要求服务端完成密码哈希（即digestPassword: true），客户端只传明文密码；SCRAM-SHA-1允许客户端或服务端哈希，但若设为客户端哈希（digestPassword: false），会破坏 FIPS 合规性 - 所有官方驱动在 2024 年后发布的稳定版均默认优先协商
SCRAM-SHA-256；若连接失败且报错含Unsupported mechanism: SCRAM-SHA-256，说明服务端版本过低（ - 如果你用的是阿里云、腾讯云或 MongoDB Atlas，它们当前部署的实例全部强制使用
SCRAM-SHA-256，配置中指定authMechanism=SCRAM-SHA-1会直接拒绝认证
连接字符串里要不要显式指定 authMechanism？
大多数现代驱动（如 Node.js 的 mongodb v5+、Python 的 pymongo v4+）会自动协商最高可用的 SCRAM 机制，无需手动指定 authMechanism。显式写死反而容易出问题。
- ✅ 推荐写法：
mongodb://user:pass@host:27017/db?authSource=admin（不带authMechanism参数） - ❌ 风险写法：
...?authMechanism=SCRAM-SHA-1—— 在只支持SCRAM-SHA-256的服务端上会报错Authentication failed，且错误信息不提示机制不匹配 - ⚠️ 特殊情况才需指定：当服务端同时开启两种机制，且你明确要降级到
SCRAM-SHA-1（例如对接老旧 Java 应用 + Spring Data MongoDB 2.x），此时必须确认服务端用户是用SCRAM-SHA-1创建的（db.createUser(..., { mechanisms: ["SCRAM-SHA-1"] })）
创建用户时 mechanism 参数怎么填？
用户机制是在创建时绑定的，不是连接时决定的。同一个用户名，用不同机制创建，就是两个独立凭证。
- 创建
SCRAM-SHA-256用户：db.createUser({ user: "u", pwd: "p", roles: [...], mechanisms: ["SCRAM-SHA-256"] }) - 创建
SCRAM-SHA-1用户：db.createUser({ user: "u", pwd: "p", roles: [...], mechanisms: ["SCRAM-SHA-1"] }) - 省略
mechanisms字段时，MongoDB 4.0+ 默认只用SCRAM-SHA-256；3.6 及更早版本默认用SCRAM-SHA-1 - 注意：
SCRAM-SHA-256用户无法用SCRAM-SHA-1连接，反之亦然 —— 错配会导致Authentication failed，日志里会写明期望的 mechanism
为什么升级后突然连不上？
典型现象是应用日志只显示 Authentication failed，没提机制问题，排查方向很窄。
- 检查服务端 MongoDB 版本：4.0+ 默认只生成
SCRAM-SHA-256凭据；如果用户是旧版本创建的，升级后未重建，就会失效 - 运行
db.system.users.find({user:"xxx"}).pretty()，看返回文档里的mechanisms字段值是什么 - 不要试图用
db.updateUser()修改已有用户的mechanisms—— 该字段不可更新；只能db.dropUser()后重建 - 如果必须保留旧机制，可在
mongod.conf中显式启用双机制：security.authorization: enabled+ 启动时加参数--setParameter enableSCRAMSHA1=true（仅限 4.2–6.0，7.0 已移除）
