authenticationfailed主因是认证数据库不匹配，用户若在admin库创建则连接必须指定authsource=admin，否则默认用目标库查找用户导致失败；其次scram-sha-256与旧客户端不兼容，需服务端禁用sha-256并重建sha-1用户。
连接时提示AuthenticationFailed，先确认认证数据库是否匹配
错误里没说清楚，但90%的情况是 authenticationDatabase 参数填错了。MongoDB 不像 MySQL 那样默认用连接时指定的库做认证——它必须明确知道“用户是在哪个库创建的”。
- 如果用户是在
admin库里用db.createUser(...)创建的，连接时必须加--authenticationDatabase admin（命令行）或在 URI 里写&authSource=admin（PyMongo） - 如果用户建在业务库如
myapp，那authSource就得是myapp，不能写成admin - PyMongo 连接字符串中漏掉
&authSource=xxx是高频错误；URI 里没这参数，默认用连接时指定的数据库名，而该库很可能没用户
SCRAM-SHA-256 导致旧客户端连不上，必须重建用户
MongoDB 6.0+ 默认只生成 SCRAM-SHA-256 凭据，但 Navicat ≤16.0.17、Robo 3T、部分老版驱动根本不支持——它们发的是 SHA-1 挑战，服务端直接拒收，报错还是笼统的 AuthenticationFailed。
- 不能靠客户端选机制绕过：服务端不协商，只按自己存的哈希格式验证
- 必须改配置并重启：
disableScramSHA256: true加到/etc/mongod.conf的setParameter块下 - 旧用户必须删掉重来：
db.dropUser("xxx")→db.createUser({ ..., mechanisms: ["SCRAM-SHA-1"] }) - 验证是否生效：
db.getUser("xxx")返回结果里要有"mechanisms" : ["SCRAM-SHA-1"]
Atlas 连接报 bad auth，别只盯着密码，先查 IP 白名单和用户作用域
Atlas 的 bad auth 错误常让人反复核对密码，其实更大概率卡在两个隐形开关上。
- IP 白名单不是“开了就行”：必须填当前机器的**实时公网 IP**，动态 IP 用户要定期更新，或者临时加
0.0.0.0/0测试 - 用户权限必须绑定具体数据库：在 Atlas UI 创建用户时，“Database User Privileges” 里选的是
admin还是your-db-name，决定了authSource值 - 连接字符串里的数据库名（
@cluster.net/xxx?...中的xxx）只是默认库，不影响认证；认证只看authSource - 密码含特殊字符（如
@、/、:）必须 URL 编码，否则 URI 解析失败，等效于传了空密码
本地部署 MongoDB 认证失败，检查 authSchema 版本和启动参数
本地跑的 MongoDB（尤其 3.x/4.x），AuthenticationFailed 往往源于 authSchema 不兼容或启动时没带 --auth。
- 启用了
authorization: enabled却没提前在admin库建管理员用户，服务起得来但所有连接都拒 - 升级过 MongoDB 版本后，旧用户凭据可能卡在低版本 schema（如
currentVersion: 3），需手动更新：db.system.version.update({"_id":"authSchema"},{$set:{"currentVersion":5}}) - Windows 下用服务方式启动时，
--auth必须写进服务注册参数，光改配置文件不生效 - 日志里搜
not authorized on admin能快速定位是权限不足还是认证库错配
authSource 填什么、用户在哪建的、哈希机制对不对、IP 白名单有没有生效——这些点不逐个敲实，重试十次结果一样。
