SCRAM-SHA-1和SCRAM-SHA-256是MongoDB默认身份验证机制，前者为4.0前默认，后者为4.0及以上默认；二者均基于RFC5802标准，使用加盐挑战响应方式，但哈希算法分别为SHA-1和SHA-256。
确认当前用户凭证使用的认证机制
连接失败时，不能只看错误里有没有 SCRAM-SHA-1 或 SCRAM-SHA-256 字样——MongoDB 默认不返回具体机制类型，只报泛泛的 Authentication failed。必须登录 MongoDB 服务端查证。
用管理员账号连上后执行：
use admin
db.getUser("your_username")
重点看返回结果中是否有 "mechanisms" : ["SCRAM-SHA-1"]。如果字段缺失、为空或显示 ["SCRAM-SHA-256"]，说明用户是用新机制创建的，而客户端（如 Navicat ≤16.0.17、旧版 Prisma 或某些 Go/mgo 驱动）不支持它。
- 用户在 MongoDB 4.0–5.x 创建且未指定
mechanisms，默认用 SHA-1 - 用户在 MongoDB 6.0+ 创建，即使没设
mechanisms，也强制用 SHA-256 -
db.updateUser()不能修改已有用户的mechanisms，只能删掉重创
检查 MongoDB 服务端是否禁用了 SCRAM-SHA-256
仅改客户端连接参数（比如加 authMechanism=SCRAM-SHA-1）没用——服务端若仍默认签发 SHA-256 凭据，用户哈希就还是 SHA-256 格式，降级参数无效。
必须修改 /etc/mongod.conf（Linux）或 mongod.cfg（Windows），在 setParameter 下显式关闭：
setParameter: disableScramSHA256: true
注意：disableScramSHA256 是开关，不是“启用 SHA-1”的配置项；不加这行，即使客户端声明 SCRAM-SHA-1，服务端也会忽略并继续用 SHA-256。
- MongoDB ≥4.2 才支持
disableScramSHA256 - 改完必须重启服务：
sudo systemctl restart mongod（Linux）或net stop MongoDB && net start MongoDB（Windows） - 重启后，新创建的用户才会真正用 SHA-1 签发哈希
验证 authSource 是否与用户所在数据库一致
Prisma、PyMongo、Go 的 mgo 等驱动默认把连接字符串末尾的数据库（如 mongodb://u:p@h:27017/mydb 中的 mydb）当作认证源，但绝大多数生产部署中用户都建在 admin 库里。
连接字符串必须显式带上 authSource=admin，否则服务端会在 mydb 里找用户，直接报 UserNotFound 或 Authentication failed。
- 正确写法：
mongodb://user:pass@localhost:27017/test?authSource=admin&authMechanism=SCRAM-SHA-1 - Navicat GUI 里，“Authentication Database” 字段不能留空，必须填
admin（或对应库名） - 如果真在
test库里建了用户，authSource=test才对，但不推荐——权限管理会混乱
避免误用已废弃的 MONGODB-CR 机制
老教程里常见 authMechanism=MONGODB-CR，这是 MongoDB 3.0 之前的老协议，从 4.0 开始彻底移除。现在用它只会触发连接拒绝，错误日志里可能只显示 sasl conversation error，看不出根本原因。
当前所有稳定版本（≥4.0）只支持两种机制：
-
SCRAM-SHA-1：兼容性好，但迭代次数少（默认 10000），安全性弱于 SHA-256 -
SCRAM-SHA-256：默认启用（6.0+ 强制），需客户端明确支持
别在连接串里写 MONGODB-CR，也别试图通过降级 MongoDB 版本来回退——问题不在版本，而在机制协商逻辑本身。
真正卡住的地方往往不是密码输错，而是服务端签发的哈希类型和客户端能解析的挑战响应格式不匹配。这种不匹配不会在错误里直说，得靠查 db.getUser() + 看服务端配置双线验证。
